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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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