У меня возник вопрос о зависимостях многоуровневой архитектуры DDD. Если реализация репозитория находится на уровне инфраструктуры, это означает, что уровень инфраструктуры зависит от уровня домена, поскольку сущности будут ссылаться в реализации репозитория.
С другой стороны, уровень домена может иметь ссылки на уровень инфраструктуры, если в домене используются службы инфраструктуры.
Разве это не создало бы циклическую ссылку?
Взгляните на луковичную архитектуру, она показывает хорошую установку для DDD. решение. (Посмотрите на мой комментарий ниже - используйте вместо этого вертикальные ломтики, если можете - стоимость лука не кажется оправданной после многих лет использования)
По сути, вся модель предметной области и интерфейсы для доменных служб считаются основными. Слои зависят только от слоев над ними, которые ближе к сердцевине. Их фактическая реализация осуществляется инфраструктурой.
Проект домена не должен ссылаться на проект инфраструктуры. Если домену нужно что-то использовать, его следует определить как интерфейс внутри домена и реализовать в проекте инфраструктуры.
В конечном итоге ваши интерфейсы - это то, что определяет ваше приложение. Логика того, как это реализуется, вынесена вовне. Поэтому я ожидаю, что у вас будут сборки с моделями домена и службами домена, интерфейс (например, MVC и т. Д.), А затем сборка инфраструктуры, которая реализует такие вещи, как NHibernate для предоставления данных и т. Д.
Вы можете увидеть различные примеры, реализующие архитектуру, в различных частях связанной статьи. Самый простой из них находится здесь
Вы можете увидеть связанные с этим вопросы здесь
Основное преимущество состоит в том, что в основном инфраструктурные проблемы будут меняться чаще всего. Новые технологии уровня данных, новое хранилище файлов и т. Д. Кроме того, ваш основной домен должен быть достаточно стабильным, поскольку он не реализует ничего, просто определяя контрактом (интерфейсами) то, что ему требуется. Помещая проблемы реализации в одно место, вы сводите к минимуму количество изменений, которые потребуются для ваших сборок.
Да в вашем случае. И у меня такой же вопрос :)
Вот мое объяснение:
Похоже, что уровень инфраструктуры - это особый слой в архитектурной диаграмме Эрика Эванса. Он реализует интерфейсы, приложение, домен.
Это немного надумано ...
Но с другой стороны, вы можете разделить инфраструктуру на отдельный модуль адаптера, поскольку компоненты инфраструктуры обычно состоят из адаптеров, трансляторов и фасадов.
Например,
1) Домен может зависеть от рассылки, если вы вставляете MailManager в DomainService. 2) Постоянство зависит от домена (случай репозитория).
Но если вы разделите рассылку и сохранение на два модуля, они не будут зависеть друг от друга. Думаю, это может решить проблему.
В конце концов, наслоение - это метод разделения компонентов, а не цель.
И последнее, но не менее важное: я ожидаю более убедительных ответов :)
