Является ли DDD-Lite языком шаблонов для внедрения зависимостей?

17

Я наткнулся на выступление Грега Янга 7 Причины, по которым проекты DDD терпят неудачу, когда он упоминает нечто, что он называет DDD-Lite, в 7:20.

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

Должен признать, что я не знаю столько о DDD, сколько хотел бы, и еще не пытался его использовать. Я также не читал книгу Эрика Эвана. я гораздо больше интересует Внедрение зависимостей, и многие, многие книги и блоги на эту тему используют термины и справочные концепции из книги DDD Эрика Эванса. Здесь я познакомился с концепциями DDD. Книги, которые я читал, которые делают это, включают:

  • Внедрение зависимостей в .NET
  • Microsoft .Net: разработка приложений для предприятия
  • Разработка приложений Brownfield в .NET

Если кто-то хочет сделать Dependency Injection, что может быть проще, чем «DDD-Lite»? Мне кажется, что создание хороших абстракций весьма полезно, независимо от того, используется ли кто-либо из концепций DDD «DDD-Lite». (см. сообщения в блоге Марка Симанна: Интерфейсы - это не абстракции , а На пути к лучшим абстракциям ). Мне трудно поверить, что все, кто делает инъекцию зависимостей, тоже делают (или должны делать) полноценный DDD. Я как-то неправильно понял аргумент Грега Янга о DDD-Lite?

.net dependency-injection domain-driven-design abstraction Matt
источник

Ответы:

15

Инъекция зависимости и DDD - это две непересекающиеся концепции. Внедрение зависимостей не требует выполнения DDD, а DDD не требует внедрения зависимостей.

Многие проекты DDD терпят неудачу, потому что они выбирают шаблоны, но пренебрегают процессом, стоящим за DDD. Они не тратят время на извлечение бизнес-правил. Они не концентрируются на модели предметной области и на тщательных абстракциях. Они не устанавливают вездесущий язык.

Короче говоря: я думаю, это недоразумение

saintedlama
источник
4
+1 Шаблоны, описанные в книге Эванса, по-прежнему ценны в гораздо более широком контексте - при условии, что каждый понимает, что применение их в изоляции не делает его DDD.
Марк Симанн
1
Да, я понимаю, DI! = DDD. @MarkSeemann, так что, похоже, аргумент Грега состоит в том, что люди говорят, что они делают DDD, когда это не так. Хорошо, я понял. Но он также утверждает, что использование абстракций, подобных найденным в DDD (агрегаты, репозитории, доменные сущности, объекты значений, сервисы и т. Д.), Не нужно, если они используются только для поддержки архитектуры с внедрением зависимостей. Это та часть, которую я не понимаю (что с ней не так). Возможно, это аргумент соломенного человека , поскольку использование таких вещей не просто для «создания языка вокруг внедрения зависимости».
Мэтт
3
Грег отчасти прав: специальные паттерны в DDD не имеют особого отношения к DI. Тем не менее, в моей книге я подобрал некоторые термины, в частности, определение «сущность против объекта ценности против службы», потому что важно понимать, что и где вводить. Однако и эта терминология, и другие шаблоны, такие как Repository и Factory, намного старше, чем книга DDD, поэтому говорить, что такие вещи не нужны вне DDD, звучит для меня неправильно. Это может зависеть от того, как вы на самом деле определяете DDD.
Марк Симанн
2

Бьюсь об заклад, Грег имеет в виду простое приложение, если вместо подхода DDD используется подмножество шаблонов, управляемых доменом. Термин DDD-Lite косвенно относится к книге http://www.infoq.com/minibooks/domain-driven-design-quickly которая раньше была популярна среди новичков DDD, но упускает из виду всю картину, фокусируясь только на моделирование локального моделирования.

Хотя Dependency Injection считается хорошей вещью, между DDD и DI нет сильной корреляции.

ZioBrando
источник