Czy DDD-Lite jest językiem wzorcowym do wstrzykiwania zależności?

17

Natknąłem się na przemówienie Grega Younga 7 powodów, dla których projekty DDD zawiodły, kiedy wspomina coś, co nazywa DDD-Lite o 7:20.

Podsumowując, w zasadzie mówi, że niektórzy używają DDD jako języków wzorcowych (bytów, repozytoriów, obiektów wartości, usług itp.) Bez robienia czegokolwiek innego związanego z DDD. Postuluje, że 60% lub więcej modeli domen w .Net to DDD-Lite. Uważa, że DDD-Lite zasadniczo buduje język wokół wstrzykiwania zależności, czego tak naprawdę nie trzeba robić. Mówi, że albo całkowicie zrób DDD, albo zrób coś prostszego. W przeciwnym razie twierdzi, że osoba wykonuje całą tę pracę w budowaniu dobrych abstrakcji, ale bez żadnych rzeczywistych korzyści.

Muszę przyznać, że nie wiem tak dużo o DDD, jak bym chciał, i jeszcze nie próbowałem go używać. Nie przeczytałem też książki Erica Evana. Jestem znacznie więcej zainteresowany Dependency Injection i wiele, wiele książek i blogów na tym zastosowaniu przedmiotem terminów i pojęć referencyjnych z DDD książki Erica Evansa. To tutaj byłem narażony na koncepcje DDD. Książki, które czytam, które to robią, obejmują:

Wstrzykiwanie zależności w .NET
Microsoft .Net: Projektowanie aplikacji dla przedsiębiorstw
Tworzenie aplikacji Brownfield w .NET

Jeśli ktoś chce wykonać wstrzyknięcie zależności, jakie są prostsze alternatywy niż „DDD-Lite”? Wydaje mi się, że budowanie dobrych abstrakcji jest całkiem przydatne, niezależnie od tego, czy używa się koncepcji z DDD w sposób „DDD-Lite”. (patrz posty na blogu Marka Seemanna: Interfejsy nie są abstrakcjami , a ku lepszym abstrakcjom ). Trudno mi uwierzyć, że wszyscy, którzy wykonują Dependency Injection, robią (lub muszą) pełnoprawną DDD. Czy w jakiś sposób źle zrozumiałem argument Grega Younga na temat DDD-Lite?

— Matt
źródło

15

Wstrzykiwanie zależności i DDD to dwie rozłączne koncepcje. Wykonanie wstrzyknięcia zależności nie wymaga wykonania DDD ani DDD nie wymaga wstrzyknięcia zależności.

Wiele projektów DDD kończy się niepowodzeniem, ponieważ wybierają wzorce, ale zaniedbują proces stojący za DDD. Nie tracą czasu na wyodrębnianie reguł biznesowych. Nie koncentrują się na modelu domeny i ostrożnych abstrakcjach. Nie ustanawiają Wszechobecnego Języka.

W skrócie: Myślę, że to nieporozumienie

— saintedlama
źródło

4

+1 Wzory opisane w książce Evansa są nadal cenne w znacznie szerszym kontekście - o ile tylko zrozumie się, że zastosowanie ich w izolacji nie czyni z niego DDD.

— Mark Seemann,

1

Tak, zdaję sobie sprawę z DI! = DDD. @MarkSeemann, więc argumentem Grega wydaje się być to, że ludzie mówią, że robią DDD, gdy nie są. Dobra, rozumiem. Twierdzi jednak również, że korzystanie z abstrakcji, takich jak znalezione w DDD (agregaty, repozytoria, jednostki domeny, obiekty wartości, usługi itp.) Jest niepotrzebne, jeśli są one używane tylko do obsługi architektury wstrzykiwanej w zależności. Tego nie rozumiem (co z tym nie tak). Być może taki argument jest słaby , ponieważ używanie takich rzeczy nie jest po prostu „budowaniem języka wokół zastrzyku zależności”.

— Matt

3

Greg jest częściowo poprawny: specjalne wzorce w DDD nie są szczególnie związane z DI. Jednak w mojej książce podjąłem pewną terminologię, szczególnie definicję bytu vs. wartość obiektu vs. usługa, ponieważ ważne jest, aby zrozumieć, co wprowadzić. Jednak zarówno ta terminologia, jak i inne wzorce, takie jak Repository i Factory, są znacznie starsze niż książka DDD, więc stwierdzenie, że takie rzeczy są niepotrzebne poza DDD, wydaje mi się niewłaściwe. Może to zależeć od tego, jak faktycznie zdefiniujesz DDD.

— Mark Seemann,

2

Założę się, że Greg odnosi się do prostej aplikacji, jeśli podzbiór wzorców opartych na domenie zamiast całego podejścia DDD. Termin DDD-Lite domyślnie odnosi się do książki http://www.infoq.com/minibooks/domain-driven-design- szybko, która była popularna wśród początkujących w DDD, ale często pomija cały obraz, koncentrując się tylko na lokalne wzorce modelowania.

Chociaż wstrzykiwanie zależności jest uważane za dobrą rzecz, nie ma silnej korelacji między DDD i DI.

— ZioBrando
źródło