Сохранение данных с несколькими источниками данных в DDD

За последние несколько месяцев мы реализовали приложение с использованием DDD и CQRS. Одна вещь, с которой я все еще борюсь, — это лучший способ сохранения данных, особенно в нескольких источниках данных разных типов.

До этого момента мы использовали уровень интерфейса DAL с несколькими частичными реализациями этого DAL. Затем на уровне нашего домена мы используем репозитории для создания/сохранения объектов нашего домена в n количестве DAL. Это работает нормально, пока мы не перейдем к более сложным операциям, таким как разбиение на страницы и поиск. Это потребовало от нас не только сопоставления наших данных, но и сопоставления критериев упорядочения/поиска/разбивки на страницы.

Я читал мнения о том, что мы должны просто выставлять уровень сохраняемости (IE Entity Framework, файловая система, веб-службы) на уровень DDD и иметь доступ к репозиториям напрямую, чтобы они могли использовать преимущества функций, встроенных в такие вещи, как ORM. Мне это кажется дырявой абстракцией.

Есть ли шаблон, который я упускаю из виду, который поможет нам решить эти проблемы?


repository c# design-patterns domain-driven-design data-persistence
person aasukisuki    schedule 06.02.2015    source источник
comment
В любом случае репозитории должны находиться в DAL. Так что они могут и должны знать о функциях, которые вы имеете в виду. Они реализуют интерфейсы из доменного уровня. Эти интерфейсы должны игнорировать эти детали реализации.   -  person EagleBeak    schedule 06.02.2015
comment
Я всегда писал наши репозитории DDD так, чтобы они были привязаны к домену, а не к данным. Это означает, что репозитории принимают и возвращают объекты домена. Если бы я вызвал метод Get в своем репозитории, и этот объект домена состоит из данных из нескольких источников, как это будет работать? По сути, сейчас у нас есть 2 набора репозиториев. Репозиторий, который применяется к домену, а затем реализации DAL, которые возвращают DTO, относящиеся к данным, хранящимся в этой реализации. Затем репозиторий Dal собирает эти DTO в объект домена.   -  person aasukisuki    schedule 06.02.2015
comment
Я согласен с тем, что репозитории принимают и возвращают объекты домена (точнее, аггергейты, верно?). DAL зависит от домена. Таким образом, не должно возникнуть проблем с созданием агрегата домена в реализации репозитория в DAL. Ваша проблема, по-видимому, связана с вашим репозиторием записи и зависит от репозитория чтения, тем самым защищая от деталей реализации, специфичных для БД, которые вы хотели бы использовать.   -  person EagleBeak    schedule 06.02.2015
comment
Хорошо, поэтому я думаю, что моя проблема может быть в 2 раза. 1) Мне нужно логически разделить мои определения репо для чтения и записи. На уровне домена мне редко (если вообще) понадобится возможность списка, страницы или поиска. 2) Я думаю, что это более тривиально для моей ситуации, но прямо сейчас мои реализации репозитория живут в моем доменном слое, и в них внедряются необходимые DAL. Поэтому мои репозитории зависят от DAL, а не наоборот. Я все еще борюсь с тем, как бы я построил совокупный объект корневого домена из нескольких DAL, если бы мне нужно было поменять местами зависимости.   -  person aasukisuki    schedule 06.02.2015
comment
Вы имеете в виду DAO вместо DAL, верно? L в DAL означает слой. Обратите внимание, что вы должны иметь возможность сохранить совокупность за одну транзакцию. Это может или не может быть сложно в вашем случае. Не должно быть проблем, если все ваши источники данных, кроме одного, предназначены только для чтения. Удачи!   -  person EagleBeak    schedule 06.02.2015
comment
Да, ты прав. DAO (реализованные в различных DAL) по сути являются репозиториями, которые возвращают DTO. Затем репозиторий на уровне домена берет эти DTO и собирает их в совокупный корень (и любые необходимые объекты-значения). Имеет ли это смысл?   -  person aasukisuki    schedule 06.02.2015

Ответы (1)


arrow_upward
3
arrow_downward

Я читал мнения о том, что мы должны просто выставлять уровень сохранения (IE Entity Framework, файловая система, веб-сервисы) на уровень DDD и иметь доступ к репозиториям напрямую.

Шаблон репозитория существует для защиты домена от сведений о сохранении. Вы, конечно, не хотите, чтобы там был дополнительный уровень абстракции. Какую бы технологию персистентности вы ни использовали, репозиторий может знать о деталях.

Затем на уровне нашего домена мы используем репозитории для создания/сохранения объектов нашего домена в n количестве DAL. Это работает нормально, пока мы не перейдем к более сложным операциям, таким как разбиение на страницы и поиск.

Вы сказали, что реализуете приложение CQRS. У вас нет читающей модели? Репозитории повторно увлажняют объекты для выполнения бизнес-кейсов записи, а не чтения.

person plalx    schedule 06.02.2015
comment
Да, у нас есть прочитанные модели, и это на самом деле отличный момент. Мы идем прямо против DAL через наш слой запросов (полностью пропуская домен), чтобы построить эти модели чтения. Может быть, моя проблема в том, что я думаю, что моим репозиториям DDD вообще нужны функции List/Paging/Search... - person aasukisuki; 06.02.2015
comment
@aasukisuki Думаю, да. Репозиторий будет реализовывать элементарные методы запросов для выполнения бизнес-команд, но это все. - person plalx; 06.02.2015