Dowiedziałem się o rozwoju opartym na domenie od dewelopera z tego obszaru. Mówił to tak, jakby chodziło o srebrną kulę zmieniających się wymagań.
Czytam wiki . Nadal nie jest zbyt jasne. Co to jest „3D” w praktyce? Czy to naprawdę niesamowite, że teraz diagramowanie klas UML jest po prostu przestarzałe?
Odpowiedzi:
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.
Ogólny opis może być -
Modeluj swoje klasy, aby odzwierciedlić struktury danych i zachowanie Twojej problematycznej domeny.
Umożliwia to mapowanie zmian w domenie problemowej bezpośrednio na zmiany w kodzie, więc aktualizacja powinna być łatwiejsza w miarę ewolucji domeny problemowej.
ZASTRZEŻENIE: Dodałem tę odpowiedź po oznaczeniu tego pytania jako duplikatu. Nie zgadzam się, ale oto jesteśmy. :-)
Projektowanie oparte na domenach ma na celu projektowanie oprogramowania w domenach o wysokiej wartości / złożoności.
To zmienia się w inne podejście do budowania oprogramowania dla przedsiębiorstw: wymaga to zbyt dużej wiedzy, a najważniejszą konsekwencją jest to, że od pierwszego strzału nie znajdziesz właściwego rozwiązania.
Lub połączenie obu.
Oba sposoby będą wymagać dobrych podstaw oprogramowania do częstego przepisywania oprogramowania. To dlatego książka podkreśliła dany zestaw wzorców wokół modelu modelu domeny: były one najbardziej rozsądną kombinacją w 2004 roku.
Jednak OOP i taktyczny wzór nie są najważniejsze. Techniczne opanowanie jest konieczne, aby zbudować świetne oprogramowanie w sposób ewolucyjny. Ale to tylko jeden składnik przepisu. Inni?