DDD против N-уровневой (3-уровневой) архитектуры

Я уже некоторое время практикую DDD с 4 отдельными уровнями: домен, представление, приложение и инфраструктура. Недавно я познакомил моего друга с концепцией DDD, и он подумал, что она привносит ненужный уровень сложности (в частности, ориентированный на интерфейсы и IoC). Обычно на этом этапе я объясняю преимущества DDD - особенно его модульность. Вся тяжелая работа и скрытые вещи находятся в инфраструктуре, и если бы я хотел полностью изменить базовый метод доступа к данным, я мог бы сделать это, просто коснувшись репозитория уровня инфраструктуры.

Аргумент моего друга состоит в том, что он мог бы таким же образом построить трехуровневое приложение:

  • Бизнес
  • Данные
  • Презентация

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

РЕДАКТИРОВАТЬ: он не использует IoC. Каждый слой в его примере зависит друг от друга.


person Josh Barker    schedule 30.09.2010    source источник
comment
Доменно-ориентированный дизайн и многоуровневая архитектура, похоже, не имеют отношения к вашему спору (и, как я их понимаю, они ортогональны друг другу). Если убрать аббревиатуры, с чем вы действительно не согласны? Кодирование интерфейсов и внедрение зависимостей?   -  person Jeff Sternal    schedule 01.10.2010


Ответы (3)


Я думаю, вы сравниваете яблоки и апельсины. Ничто в N-Tier не запрещает ему использовать интерфейсы и DI для упрощения модульного тестирования. Точно так же DDD может выполняться со статическими классами и жесткими зависимостями.

Кроме того, если он реализует бизнес-объекты и использует репозитории, это звучит так, как будто он выполняет DDD, а вы спорите немного больше, чем о семантике.

Вы уверены, что проблема не только в использовании DI / IoC или нет?

person quentin-starin    schedule 30.09.2010
comment
Как можно легко протестировать что-то без использования IoC? У него могут быть интеграционные тесты, но как бы вы проводили модульное тестирование без интерфейсов / IoC / DI? - person Josh Barker; 01.10.2010
comment
Я говорю, что DDD или N-Tier не подразумевают IoC или нет. Похоже, вы пытаетесь сфокусировать вопрос на DDD и N-уровне, но на самом деле ваш вопрос, похоже, задает IoC / DI vs. no IoC / DI. fwiw, я был бы на вашей стороне, поддерживая IoC / DI. Я просто не думаю, что DDD или N-Tier вообще актуальны, поскольку любой из них может быть выполнен с DI / IoC или без него. - person quentin-starin; 01.10.2010

Я думаю, вы смешиваете несколько методологий. DDD - это разработка, управляемая доменом, цель которой - сделать бизнес-домен частью вашего кода. То, что вы описываете, больше похоже на луковичную архитектуру (ссылка), а не на «нормальный» трехуровневый подход. Нет ничего плохого в использовании трехуровневой архитектуры с DDD. DDD зависит от TDD (TestDriven Developement). Интерфейсы помогают с TDD, поскольку легче тестировать каждый класс по отдельности. Если вы используете Dependency Injection (и IoC), это еще больше смягчается.

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

Надеюсь, это немного проясняет ситуацию - теперь с небольшими изменениями!

person Goblin    schedule 30.09.2010
comment
Хммм ... Я хорошо знаком с луковой архитектурой Джеффа Палермо, так как в моем проекте есть эти отдельные слои, и я основывал его на его сообщении в блоге. Тем не менее, все эти уровни также существуют в проекте DDD (например, домен, приложение, представление и инфраструктура). - person Josh Barker; 30.09.2010
comment
Я хотел сказать, что, хотя структура объединения используется многими, кто также использует DDD, она не является обязательным условием для DDD. - person Goblin; 30.09.2010
comment
Для дальнейшего развития - для практики DDD - вам не нужен конкретный набор слоев, и они не должны быть структурированы определенным образом. Однако все, что вы кодируете, должно моделировать целевой домен, включая бизнес-объекты, имеющие те же имена, что и их реальные аналоги. - person Goblin; 30.09.2010
comment
Однако разница в том, что в рамках описанного мною трехуровневого подхода без использования IoC каждый уровень знает и зависит друг от друга ... разве это не антипаттерн? - person Josh Barker; 30.09.2010
comment
Сам по себе это не антипаттерн, но я согласен с тем, что использование структуры лука ослабляет связь, поскольку бизнес-уровень не зависит от уровня инфраструктуры. Я предпочитаю лук традиционной трехслойной модели. Но я по-прежнему считаю, что использование трехуровневой архитектуры вполне возможно, если вы не верите в обмен, например. ваш ORM: см. эту ссылку, чтобы узнать, почему: ayende.com/Blog/archive/2010/07/30/ - person Goblin; 30.09.2010
comment
Использование контейнера IoC - это компромисс, поскольку он вносит сложность в более слабую связь. Все дело в том, что вам нужно. РЕДАКТИРОВАТЬ: И вы по-прежнему можете использовать интерфейсы и внедрение зависимостей между вашими уровнями в трехуровневой архитектуре для облегчения тестирования. - person Goblin; 30.09.2010
comment
Я начинаю понимать, откуда вы ... если вы отредактируете свой ответ, я могу поменять свой голос. - person Josh Barker; 01.10.2010

N Tier или, в данном случае, трехуровневая архитектура отлично работает с модульными тестами. Все, что вам нужно сделать, это IoC (инверсия управления) с использованием внедрения зависимостей и шаблона репозитория.

Бизнес-уровень может проверять и готовить возвращенные данные для уровня презентации \ веб-API, возвращая точные данные, которые требуются. Затем вы можете использовать mock в своих модульных тестах на всех уровнях. Вся ваша бизнес-логика и потребности могут быть на уровне bl. А слой Dal будет содержать репозитории, введенные с более высокого уровня.

person boaz levinson    schedule 06.05.2021