Domain-Driven Design – projektowanie złożonych modeli biznesowych.
Podczas pracy nad projektami, programiści często spotykają się z podobnymi wyzwaniami:
- projekt posiada identyczny kod w wielu miejscach – złamanie reguły DRY (Don’t Repeat Yourself),
- obiekty posiadają stan, który logicznie do nich nie pasuje – złamanie reguły SRP (Single Responsibility Principle),
- patrząc na kod nie potrafimy odgadnąć za co odpowiedzialna jest dana metoda lub klasa.
W dodatku reguły biznesowe zaczynają się mieszać, brak jest wspólnego modelu i w konsekwencji nie rozumiemy co robi aplikacji. Z czasem dużą trudnością okazuje się wprowadzanie kolejnych zmian. Finalnie kod aplikacji zamienia się w spaghetti code – czyli trudny do zrozumienia kod programu.
Aby zapanować nad złożonym projektem i wyeliminować większość wymienionych problemów stworzono podejście Domain-Driven Design, które przez wiele organizacji jest uznawane jako idealny sposób tworzenia oprogramowania. DDD sprawdzi się tam gdzie mamy do czynienia ze złożonym modelem. Oczywiście nie każde oprogramowanie jest złożone i powinno być rozwijane zgodnie z DDD. Na przykład prosty blog, czy aplikacja typu CRUD.
Stosowanie DDD rodzi wiele korzyści. Po pierwsze pozwala na podzielenie złożonego systemu na moduły (Bounded Context). Dzięki temu aplikacja jest skalowalna, łatwiejsza w utrzymaniu i testowaniu. Wprowadzanie kolejnych zmian biznesowych jest prostsze. Po drugie paradygmat DDD promuje dogłębne zrozumienie dziedziny biznesowej. Komunikacja w zespole deweloperskim jest sprawniejsza ponieważ wszyscy posługują się tym samym słownictwem (Ubiquitous Language) i kod programu bardziej uwypukla domenę biznesową.
Model
Model domeny to uproszczony model abstrakcji w którym funkcjonuję przedsiębiorstwo. W podejściu DDD model nie jest tym samym co baza danych. W klasycznym podejściu trójwarstwowym (warstwa prezentacji, logiki oraz dostępu do danych) często pojawiają się boskie klasy (God Classes), które posiadają zbyt dużą odpowiedzialność. Praca z takimi obiektami jest trudna z powodu stopnia skomplikowania kodu w takiej klasie. Popularnym przykładem są tu wszelkie serwisy, których kod może spuchnąć do kilku tysięcy linijek. Podejście klasyczne prowadzi również do powstawania anemicznych encji, czyli takich klas, które nie posiadają zachowania a jedynie stan.
DDD proponuje podział aplikacji na warstwę domeny biznesowej i wokół tej warstwy są rozwijane kolejne bardziej techniczne warstwy (warstwa infrastruktury czy dostępu do bazy danych). Warstwa domeny biznesowej nie jest obciążona kodem infrastruktury technicznej i nie posiada zależności do zewnętrznych bibliotek. Logika aplikacji rozwijana w ten sposób jest łatwo testowalna i łatwo przenaszalna.
Język wszechobecny
Programiści w rozmowach używają żargonu technicznego. Przewijają się pojęcia takie jak serwis, encja, klasa czy kontroler. Z drugiej strony klient używa słownictwa, który pochodzi z branży w jakiej pracuje. Jeżeli każdy z uczestników projektu posługuję się innymi słowami do opisu tego samego pojęcia, dochodzi do nieporozumień.
Dzięki dostępowi do eksperta dziedzinowego podczas współpracy z programistami powstaję wspólne słownictwo, które będzie używane przez wszystkich. Podczas spotkań, analiz powstaję wspólny język, który jest odkrywany z domeny biznesowej. W kodzie programu i wszystkich formach komunikacji używamy języka wszechobecnego.
Kontekst ograniczony
Podczas modelowania systemu należy wyznaczyć granicę kontekstów używając Bounded Contextów. Każdy kontekst to niezależny byt i może być rozwijany przez osobny zespół. Podczas tworzenia modelu w obszarze danego Bounded Contextu, powinniśmy zaimplementować elementy które są ze sobą powiązane i tworzą spójną logiczną całość. Bounded Contexty nie mogą komunikować się ze sobą bezpośrednio i posiadają oddzielny model. Do komunikacji pomiędzy kontekstami możemy wykorzystać zdarzenia domenowe. Technika ta pozwala na swobodniejsze wprowadzanie zmian i każdy z zespołów pracujący w ramach swojego Bounded Contextu nie przeszkadza innym zespołom.
Agregaty
Agregat to z technicznej perspektywy graf obiektów. Agregaty to elementy, które stanowią spójną całość w odpowiedzi na zmianę w oprogramowaniu. Agregaty wymuszają na programistach hermetyczność w ramach znaną z programowania obiektowego. Najważniejsza sprawa podczas modelowania agregatów to określenie jego granic. Zbyt duże agregaty są przyczyną niepowodzeń utworzonych modeli biznesowych.
Podsumowując jednym z możliwych panaceum na złożony projekt informatyczny jest podejście Domain-Driven Design. DDD pozwala na opanowanie bałaganu, który panuje w kodzie oprogramowania. Ważnym czynnikiem który może się przyczynić do sukcesu stosowania DDD jest umiejętne podzielenie domeny biznesowej na Bounded Contexty.
Autor
Zobacz inne nasze artykuły
Wymiary +/- VS tolerancje geometryczne – jak nowoczesny język specyfikacji geometrycznej wyrobów może pomóc w rozwoju Twojej firmy.
Artykuł ten przeznaczony jest dla wszystkich zaangażowanych w procesy związane z definiowaniem, interpretacją i zarządzaniem dokumentacją techniczną dla komponentów…
Domain-Driven Design – projektowanie złożonych modeli biznesowych.
Podczas pracy nad projektami, programiści często spotykają się z podobnymi wyzwaniami: W dodatku reguły biznesowe zaczynają się mieszać, brak…
Kształcenie liderów jednym z wyzwań rynku IT
Świat IT, szczególnie dla ludzi spoza branży, często kojarzy się głównie ze skomplikowanymi technologiami i zaawansowanymi umiejętnościami technicznymi. Jednak…
