Cóż, po pierwsze, nie sądzę, że artykuł w Wikipedii, do którego się odwołujesz, jest bardzo dobry, głównie dlatego, że odwołuje się do wielu rzeczy, które są jedynie pomocnicze w projektowaniu opartym na domenach i niewiele robi, aby oświecić kogoś o praktyce.
Ale jako ktoś, kto wziął sobie do serca Domain Driven Design (co zwykle jest warte DDD, a nie 3D, ponieważ jest tego warte), zawsze czułem, że podstawy DDD są oczywiste, jeśli czytasz tyle, co pierwszy rozdział Erica Książka Evansa. Ale jest to zestaw wzorców i praktyk, więc nie jest tak łatwo przedstawić 3 zdanie podsumowujące, co to jest i jakie są zalety bez wchodzenia w szczegóły. Które szczegóły rezonują z jakąkolwiek osobą, mogą być również bardzo różne; jest prawdopodobne, że 10 lat temu sam bym tego nie widział.
DDD nie jest srebrną kulą. Realizowane rozsądnie, polegają na podejściu rzemieślniczym do budowania oprogramowania i uznaniu potrzeby ograniczenia tarcia poznawczego między zespołami programistycznymi a firmami, dla których budują oprogramowanie. Jedną z najważniejszych praktyk jest posiadanie warstwy, w której słownictwo domenowe używane przez zespół programistów i zespół biznesowy jest możliwie ściśle dopasowane. Tę warstwę budujesz iteracyjnie, gdy rozumiesz problem biznesowy, który próbujesz rozwiązać. Kiedy logika biznesowa jest rozsądnie zakodowana w tej warstwie, odizolowana od wszystkich zawiłych zależności, jakie zwykle mają aplikacje korporacyjne, poprzez połączenie interakcji z tymi systemami w interfejsy, język używany w rzeczywistej warstwie domenowej staje się w końcu dość zwięzły, oczywisty i czytelny.
Biorąc pod uwagę kształt, w jakim widziałem większość oprogramowania dla przedsiębiorstw, w praktyce może brzmieć DDD jak srebrna kula, ponieważ większość oprogramowania dla przedsiębiorstw ma tak słabą separację obaw, że jest prawie nie do przetestowania, a zespół oprogramowania obawia się zmian, ponieważ nie mają pojęcia, jakie mogą być skutki uboczne pozornie trywialnych zmian w kodzie, podczas gdy odpowiednio ustrukturyzowana warstwa domeny będzie niezależnie testowana i weryfikowalna. Ale w rzeczywistości DDD przyznaje, że systemy rzadko istnieją w izolacji. DDD obejmuje wzorce radzenia sobie ze starszymi systemami (warstwa antykorupcyjna, ograniczone konteksty, żeby wymienić tylko kilka).
Jeśli ćwiczysz projektowanie obiektowe, w tym dyscyplinę luźnego łączenia i ćwiczysz testy jednostkowe dość religijnie, i bezlitośnie refaktoryzujesz kod, a podczas budowy systemu pracujesz z ekspertami w dziedzinie, zasadniczo uzyskasz wynik, który w zasadzie o czym mówią zwolennicy projektowania opartego na domenach.
Istnieje kilka specyficznych wzorców opisanych w książce Evansa, które odnoszą się głównie do tworzenia oprogramowania dla przedsiębiorstw, a niektóre z nich są dość uniwersalnymi zasadami, ale zasadniczo DDD jest pragmatycznym podejściem do tworzenia oprogramowania, które z czasem może zmniejszyć narastanie zadłużenia technicznego, i spraw, aby Twoi klienci byli szczęśliwsi, ponieważ jesteś w stanie mówić tym samym językiem i dostarczać lepiej działające rozwiązania ze względu na zalety lepszego wzajemnego zrozumienia.
