Является ли 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?

Ответы:


15

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

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

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


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 нет сильной корреляции.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.