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

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

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

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

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

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

5
задан Josh Barker 30 September 2010 в 20:10
поделиться