DDD vs Архитектура N-Tier (3 уровня)

Question

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

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

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

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

EDIT: Он не использует IoC. Каждый слой в его примере зависит друг от друга.

Answer 1

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

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

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

Answer 2

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

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

Надеюсь, что это немного почистит - теперь с незначительным редактированием!