Домен Управляемый Дизайн

Question

Схема наложения для DDD предполагает, что слои должны быть;

Представление / Application / домен / Инфраструктура

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

Answer 1

Этот вопрос был задан с использованием слова «слой», поэтому мой первоначальный ответ касался слоев. Вероятно, лучше начать с того, что DDD - это не жесткие слои, а создание приложения таким образом, чтобы его можно было легко тестировать и изменять, поскольку оно поощряет разделение проблем между различными объектами.

Мне не нравится называть домен «слоем», потому что доменные объекты на самом деле не образуют слой в обычном смысле, они передаются между слоями, но не принадлежат ни одному из них. Что касается уровня доступа к инфраструктуре на уровне представления, на диаграмме говорится, что это вариант. От вас зависит, насколько абстрагироваться от доступа к инфраструктуре из презентации. В большинстве случаев я бы хотел пройти через уровень приложения, чтобы избежать привязки его к деталям реализации, но прямой подход - вариант, решение за вами.

Я думаю, что чтение книги Эванса немного расстраивает из-за отсутствия конкретных примеров, но он пытается сделать ее широко применимой, и некоторые языки намного более гибки, чем другие, поэтому они могут действовать по-другому. Например, когда я использую Java и Hibernate, у меня нет ссылок из домена на объекты доступа к данным, я думаю, что реализации постоянных коллекций Hibernate служат как хранилища, позволяя ленивый обход модели домена. Но это решение по реализации, основанное на моем выборе языка и библиотек, и другие ситуации могут оправдать разные решения.

Answer 2

Хм, ИМХО DDD не столько о «наслоении». Это больше о моделировании проблемы, которую вы пытаетесь решить, чтобы ваша модель (сущности, объекты значений, репозитории, сервисы, спецификации) отражала проблемную область реального мира.

Однако действительно существует какое-то «разделение» между классами, которые вы пишете, но я бы на самом деле не назвал это «многоуровневым», так как ИМХО, совершенно нормально, что ваши классы представления и доменные классы имеют доступ инфраструктура, например. Тем не менее, доменные классы не должны зависеть, например, от классов представления, но обратное может быть истинным.

Я в основном организовываю свои проекты следующим образом:

• a имеет сборку, которая содержит материалы, относящиеся к презентации. (Формы и т.д ...)
• У меня есть сборка, которая содержит «домен». Это включает в себя объекты, хранилище интерфейсы, классы спецификаций и т.д ...
• другая сборка, которая содержит реализации репозитория.
• набор инфраструктурных сборок:
  • общий dll 'framework', который содержит утилиты, которые я могу использовать в своей презентации, в своих классах домена и т. Д. *
  • dll, который содержит помощников для доступа к БД (в моем случае, тонкая оболочка вокруг NHibernate).

Вопреки тому, что говорит Натан Хьюз, я думаю, что это нормально, что у вашего уровня представления есть доступ к инфраструктуре, так как я иногда опускаю «уровень обслуживания приложений». В таком случае мой уровень представления - это мое приложение. Я также использую NHibernate, и для меня нормально, что мой уровень презентации обращается к помощникам NHibernate. Поскольку мое приложение (в некоторых случаях это мой уровень представления) является единственной «вещью», которая знает контекст приложения. Так, например, именно он отвечает за запуск и совершение транзакций.

(Как говорит Эванс в главе 5, я думаю: контекст - это король).