Чи 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

Якщо ви хочете зробити введення залежностей, які простіші альтернативи виконувати "DDD-Lite"? Мені здається, що створення хороших абстракцій є досить корисним, незалежно від того, чи використовується концепція DDD "DDD-Lite". (див. повідомлення в блозі Марка Семана: Інтерфейси - це не абстракції , а назустріч кращі абстракції ). Мені важко вірити, що кожен, хто робить ін'єкцію залежностей, теж робить (або потрібно робити) повноцінним DDD. Чи я якось неправильно зрозумів аргумент Грега Янга щодо DDD-Lite?

— Метт
джерело

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, але безліч пропускає всю картину, зосереджуючись лише на схеми дизайну локального моделювання.

Хоча введення залежностей вважається хорошою справою, немає сильної кореляції між DDD та DI.

— ZioBrando
джерело