Kiedy nie powinniśmy stosować podejścia opartego na Domain-Driven Design?

Question

Czytałem o DDD, że w obliczu tego ustępu

dla danych operacji centric byś prawdopodobnie lepiej wyłączyć za pomocą coś jak Active Record wzór, a nawet DAL nad procedur przechowywanych. Możesz znaleźć pewne korzyści w niektórych pobieżnych aspektach DDD i być może używając jakiejś terminologii, ale próbując sprawić, by DDD pasował tutaj, nie będzie przyjemnym doświadczeniem.

jak ten:

Prawdopodobnie 95% wszystkich aplikacji wpaść w „nie tak dobre dla używając DDD” kategorie. Większość z nich to przede wszystkim DataCentric - większość stron internetowych to ... Większość aplikacji do aktualizacji danych i raportowania jest zorientowana na dane.

Co myślisz? Czy akceptujesz tę opinię? Zgodnie z tymi paragrafami nie mogliśmy użyć DDD do szerokiego wachlarza projektów IT, mogliśmy?

Answer 1

Podejmij te liczby po prostu jako pewne wartości oparte na doświadczeniu autora (książka Evansa została wydana ponad 13 lat temu, od tego czasu sytuacja się zmieniła).

Przede wszystkim rzeczą, którą (niestety) niewielu programistów rozumie, jest to, że DDD dotyczy sposobu myślenia, sposobu patrzenia na rzeczy. to jest to! Możesz więc użyć DDD w każdym projekcie, ponieważ wciąż musimy najpierw zrozumieć domenę, niezależnie od jej implementacji. Jeśli się okaże, że domena to tylko kilka struktur danych, nie musisz komplikować życia. Zwłaszcza jeśli budujesz "głupią" aplikację, czyli interfejs dla bazy danych.

Ale jeśli budujesz aplikację, która musi zrozumieć semantykę biznesową (koncepcje i zachowanie) w celu zautomatyzowania rzeczy, to jest to inna historia, a wszystkie te pojęcia DDD pomogą ci zbudować łatwiejszą w utrzymaniu aplikację.

Wszystko zależy od aplikacji i nawet w tej aplikacji rzeczy mogą się bardzo różnić. Powinieneś najpierw zrozumieć cel aplikacji, następnie domenę, którą próbuje reprezentować (jeśli tak jest) i wymyślić rozwiązanie dla każdego przypadku użycia. W jednej aplikacji możesz mieć wiele rzeczy związanych z CRUD i możesz być bardzo wydajny, pomijając wiele abstrakcji. Możesz mieć kilka ważnych pojęć i przypadków użycia, które wymagają znacznie lepszego zrozumienia i zaprojektowania. Ma również znaczenie, jak bardzo uważasz, że aplikacja zmieni się z czasem. Jeśli istnieją oznaki, które będą ewoluować w miarę upływu czasu, lepiej będzie trochę abstrakcjonować, ale tylko z punktu widzenia projektu. Wdrożenie wciąż może być CRUDy w tym momencie.

Jeśli traktujesz metodologię jako grupę myślenia i pojęć, możesz użyć jej wszędzie, ponieważ coś takiego jak DDD nie jest receptą na "jak to zrobić". Chociaż ma kilka konkretnych narzędzi, projektant aplikacji powinien zdecydować, czy są one dobre dla Twojej aplikacji.

Po prostu musisz użyć DDD, aby zdecydować, czy (całość) DDD może być użyta w niektórych częściach aplikacji. Ale znowu DDD oznacza podejście strategiczne, sposób myślenia.

Po prostu nie można wybrać rozwiązania od samego początku dla całej aplikacji.Zapoznaj się z problemami, które aplikacja stara się rozwiązać i użyj właściwego rozwiązania dla każdego problemu. Jeśli w końcu wszystko jest po prostu CRUD, to jest w porządku. Równie dobrze, jeśli tylko niektóre części są zaimplementowane za pomocą narzędzi taktycznych DDD, chodzi o to, aby znaleźć optymalne rozwiązanie problemu.

Podsumowując, poznaj i zrozum nasz sposób myślenia DDD (istnieje wiele wyjaśnień, skup się na projekcie, a nie na przepisach, ponieważ są one błędne), unikaj traktowania tego jako przepisu kodującego i po prostu go używaj, aby określić najlepsze podejście do potrzeb aplikacji.

Answer 2

DDD to zbiór pomysłów. Kiedy mówisz, użyj ,, nie jestem pewien, co masz na myśli. Na przykład, powszechnie używany język jest prawdopodobnie dobrym pomysłem, jeśli zamieniasz firmę w kod. Przydatne mogą być również typy wartości.

Ale pomysły takie jak ograniczają kontekst i agregat korzenie? Rozwijanie w tym stylu będzie miało większy koszt, ponieważ projekt stanie się naturalnie bardziej złożony. W niektórych domenach problemów konieczne jest odizolowanie problemu domeny. A to dlatego, że problem jest trudny. Innymi słowy, 95% systemów nie rozwiązuje trudnych problemów, które uzasadniają koszt złożoności.

Lubię myśleć o DDD jako istniejącym w jakimś spektrum projektowym.
Coś jak:

<--CRUD----Active Record----Domain Model----DDD--> 

Od lewej do prawej, te pomysły wzrastać w złożoności. I naturalnie przemieszczasz się od lewej do prawej, kiedy rozwijasz projekt kodu. Dobrą praktyką jest odłożenie decyzji dotyczących projektowania (architektury) tak późno, jak to możliwe. Zawsze możesz zacząć od czegoś po lewej i przesuwać się w prawo.

Answer 3

Vaughn Vernon przywołuje w swojej wielkiej książce swoją DDD scorecard.

Jeśli twoja aplikacja jest ukierunkowana na CRUD, DDD będzie YAGNI.
W przeciwnym razie, jeśli twoja aplikacja jest naprawdę zorientowana na zadania, wychwytując konkretny zamiar użytkownika, DDD może ci naprawdę pomóc.