👉 Domain Driven Design 😱

Z pewnością DDD nie jest dla każdego. Jeżeli dopiero zaczynasz swoją ścieżkę programisty to koncepty poruszane w tym artykule prawdopodobnie do Ciebie nie trafią. Mimo wszystko zachęcam do lektury.

Cześć 

Techniki DDD zyskały swą popularność w roku 2003, wraz z publikacją książki Erica Evansa. Mimo upływu lat koncepcja DDD jest wciąż żywo rozwijana i wzbogacana o nowe techniki.

W dzisiejszym artykule:

• Zrozumieć DDD
• Podstawowe koncepty DDD
• Trudności związane z DDD

Zrozumieć DDD

Domain Driven Design jest zestawem technik i koncepcji służących do projektowania złożonych modeli biznesowych i ich dosłownej implementacji. Naszym zadaniem, jako programistów jest zrozumienie faktu, iż technologia w jakiej rozwiązujemy problem nie jest istotna. Nasza uwaga powinna skupiać się na biznesie. Dążymy do zrozumienia wartości biznesu, tego co robimy i w jaki sposób przekłada się to na $.

Fundamentalnym zagadnieniem DDD jest relacja biznes <=> zespół. Kod, wytwarzany przez zespół musi opierać się na domenie w jakiej pracujemy. Każda domena ma jakieś reguły, walidacje, kompromisy – generalnie zasady biznesowe. I tu pojawia się pierwsza ściana – musimy poznać domenę. W jaki sposób poznaje się domenę opiszę w kolejnym artykule – na dziś niech wystarczy Ci wiedza, że musisz znaleźć osobę / osoby, które bardzo dobrze znają problem od strony biznesu.

Tak jak na obrazku powyżej – domena będzie się zazwyczaj składała z kilku subdomen. Podczas odkrywania domeny z biznesem będą pojawiały się zarysy, które na podstawie doświadczenia / przeczucia / konsultacji z innymi będziesz definiował.

A zatem jak rozumieć Domain Driven Design? Wyróżniłbym tutaj 3 główne zasady, DDD:

• koncentruje się na podstawowej domenie i logice domeny
• opiera złożone projekty na modelach domeny (to domena jest najważniejsza)
• polega na współpracy z ekspertami dziedzinowymi w celu ulepszania modelu aplikacji i rozwiązywania wszelkich pojawiających się problemów związanych z domeną

Podstawowe koncepty DDD

Kiedy czytamy o DDD na pewno spotkamy się z pojęciem Ubiquitous Language. W praktyce oznacza to wspólny język modelu, którym posługuje sią cały zespół, począwszy od eksperta domenowego po programistów warstwy logiki domenowej. Jest to przy okazji jedna z zalet aplikacji opartych o projektowanie domenowe.

Innym konceptem są Bulding Blocks, czyli język standardowych wzorców, z których budujemy modele. Tutaj pozwolę sobie skopiować część artykułu bottegi, która jest zresztą doskonałą lekturą DDD (w większość konceptów wejdziemy z czasem):

• Entity – identyfikowalne obiekty zawierające odpowiedzialność biznesową;
• Aggregate – hermetyczne grafy obiektów, z jedną encją będącą „korzeniem agregatu”, która stanowi API całości. Agregat jest główną jednostką logiki domenowej w DDD;
• Value Object – wrapper dla typów prostych, nadający im znaczenie biznesowe oraz wygodny interfejs;
• Service – specyficzne operacje, które nie pasują do żądnego agregatu;
• Policy – model wariacji operacji biznesowych, Strategy Design Pattern;
• Specification – model złożonych warunków biznesowych, wywodzi się z Composite Design pattern;
• Event – model wydarzeń biznesowych, może służyć do przetwarzania równoległego lub komunikacji pomiędzy Bounded Context;
• Saga – model złożonego procesu, który stan jest trwały oraz zależy od wielu zdarzeń;
• Factory – tworzy nowe instancje złożonych Agregatów, dbając o ich poprawność. Zwiększa testowalność, biorąc niejako na siebie operatory new;
• Repository – zarządza trwałością Agregatu/Encji.

Trudności związane z DDD

Podstawowym problemem jest komunikacja i znalezienie eksperta domenowego. Jeżeli takiej osoby nie ma to nic nie wyczarujemy. Możemy zgadywać jak ma wyglądać domena ale to nie jest dobre rozwiązanie. Prędzej lub później okaże się, że pomyliliśmy koncept i nie o to chodziło biznesowi – a wtedy zmiany mogą być bolesne…

Kolejną trudnością są kompetencje zespołu developerskiego. Jeżeli żaden z programistów całkowicie nie wie o co chodzi w DDD to prawdopodobnie nic z tego nie wyjdzie. Albo i wyjdzie ale ogromnym kosztem. Na szczęście jest kilka przykładowych projektów w sieci na bazie której możemy czerpać wiedzę i inspirację.

Choć ten przykład w dzisiejszych czasach nie stanowi już aż tak wielkiego problemu to mimo wszystko warto o tym wspomnieć. DDD wymaga pracy w procesie iteracyjnym. Domena jest żywa – dochodzą nowe reguły, inne się zmieniają, zmienia się prawo. To kieruje projekty rozwijane w metodologii DDD do bycia agile.

DDD nie pasuje wszędzie. Techniki te są opłacalne dla projektów operujących na złożonych i nietrywialnych domenach. Nie każdy projekt jest na tyle skomplikowany, że musimy ich używać . Jeżeli mamy prosty proces CRUD’owy z zerową lub marginalną warstwą reguł biznesowych to osadzenie domeny (ciekawe czym ona jest w takim crudzie) tylko niepotrzebnie skomplikuje projekt. Nie po to pojawił się koncept Domain Driven Design.

Podsumowanie

Projektowanie oparte na domenie to podejście inżynierii oprogramowania do rozwiązywania konkretnego modelu domeny. Rozwiązanie krąży wokół modelu biznesowego, łącząc wykonanie z kluczowymi zasadami biznesowymi. W dużych projektach zwykle tylko część modelu (Core Domain) będzie spełniać warunek gdzie DDD powinno być zastosowane. Moim zdaniem jest to jak najbardziej poprawne aby tylko dla części projektu zastosowane było to podejście. Jasne jest, że wpływają na to inne czynniki, np. kompetencje zespołu :).

Źródła:

• Domain Driven Design and Development In Practice
• Domain Driven Design krok po kroku
• What is DDD – Eric Evans – DDD Europe 2019
• WJUG #177 – Domain Driven Design w praktyce – Krzysztof Muchewicz

Za tydzień

Lecimy w świat DDD – omówimy w jaki sposób poznawać domenę.