Упаковка репозиториев и их интерфейсов в DDD

В приложениях, следующих за DDD, над которыми я работал, у нас, как правило, есть уровень служб, который содержит службы + репозитории + интерфейсы для репозиториев и служб, все они находятся в одной сборке, а модель предметной области будет жить в другой сборке. Такое ощущение, что все, что не соответствует модели предметной области, загромождено в этом одном большом проекте.

В приложении, которое следует принципам и шаблонам DDD, как вы упаковываете репозитории и интерфейсы, которые они реализуют? Каковы лучшие практики для упаковки различных логических частей приложения DDD (или упаковки в целом в этом отношении)? Должен ли каждый логический раздел жить в своей собственной сборке? Это вообще имеет значение?


c# domain-driven-design ddd-repositories
person kabaros    schedule 23.09.2012    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Я бы посмотрел на луковую архитектуру. В основном вся модель предметной области и интерфейсы для доменных служб считаются основными. Слои зависят только от вышележащих слоев, которые ближе к сердцевине. Их фактическая реализация осуществляется инфраструктурой.

См. Здесь http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

В конечном итоге ваши интерфейсы - это то, что определяет ваше приложение. Логика того, как это реализуется, воплощается в жизнь. Поэтому я ожидаю, что у вас будут сборки с моделями домена и службами домена, интерфейс (например, MVC и т. Д.), А затем сборка инфраструктуры, которая реализует такие вещи, как NHibernate для предоставления данных и т. Д.

Вы можете увидеть различные примеры, реализующие архитектуру, в различных частях связанной статьи. Самый простой - здесь https://bitbucket.org/jeffreypalermo/onion-architecture/get/1df2608bc383.zip

Вы можете увидеть связанные с этим вопросы здесь https://stackoverflow.com/questions/tagged/onion-architecture

Основное преимущество состоит в том, что в основном инфраструктурные проблемы будут меняться чаще всего. Новые технологии уровня данных, новое хранилище файлов и т. Д. Также ваш основной домен должен быть достаточно стабильным, поскольку он не реализует ничего, просто определяя контрактом (интерфейсами) то, что ему требуется. Помещая проблемы реализации в одно место, вы сводите к минимуму количество изменений, которые потребуются для ваших сборок.

person GraemeMiller    schedule 23.09.2012
comment
Отличная ссылка на луковичную архитектуру, о которой я вообще не знал. Благодарю. - person kabaros; 24.09.2012

arrow_upward
0
arrow_downward

Вы можете найти рекомендации по созданию слоев в книге DDD . У вас в основном есть:

  • Домен
  • Инфраструктура
  • заявка
  • UI

Службы бывают трех видов: служба уровня приложений, служба уровня инфраструктуры и служба уровня домена, в зависимости от того, что делает служба. Что касается репозиториев, их контракты (интерфейсы) часто находятся в домене, а их конкретные реализации находятся на уровне инфраструктуры.

Что касается сборок, я бы рекомендовал хотя бы по одной на каждый слой. Сборки и библиотеки DLL предназначены для повторного использования, разделения задач и разделения - смогу ли я выбрать эту DLL и отбросить ее, чтобы повторно использовать в другом приложении? Смогу ли я сделать это, не таща за собой кучу несвязанных функций, которые внесут ненужную сложность в другое приложение? Смогу ли я легко заменить свою dll на другую, просто изменив одну строку кода в моем модуле внедрения зависимостей? и так далее.

person guillaume31    schedule 24.09.2012