Niektórzy ludzie mówią, że DDD jest trudne, kosztowne i powinno być stosowane z ostrożnością. Niektóre zespoły praktykują „DDD Life” — używają wzorców projektowania aplikacji opisanych przez Erica Evansa w dużej niebieskiej książce, ale ignorują idee, które uważa się za naprawdę ważne.
Prawdę mówiąc, nigdy nie pracowałem nad projektem z użyciem „prawdziwego DDD” (na razie!). Mimo to DDD mnie zainspirowało i wierzę, że sprawiło, iż stałem się bardziej profesjonalnym programistą. Stosuję małe fragmenty i elementy DDD, z których większości nie da się nazwać „prawdziwym DDD”, ale dokładnie pamiętam, skąd bierze się ta inspiracja.
Uważam, że prawdziwa wartość pracy Evansa polega na tym, że praktycznie każdy może wykorzystać niektóre z idei, które zaproponował. Nie wymagają żadnych specjalnych narzędzi, pieniędzy, uzgodnień ani reorganizacji. To proste pomysły, które możesz zacząć wdrażać już od poniedziałku (albo jutro). Te idee nazywam „DDD Ultra-Lite”. Niektóre z nich nie są nowe, ale wierzę, że Evans dobrze wykonał swoją pracę, opisując DDD zrozumiałymi słowami i metaforami, aby uniknąć momentów nieporozumień.
Oto te idee (w losowej kolejności):
1. Słuchaj tego, co mówi biznes
Nie żartuję. Ta rada jest prawdopodobnie tak stara jak samo programowanie, ale Evans opisuje tę ideę w dość interesujący sposób.
Mówi, że jeśli biznes nie rozumie twojego modelu albo uważa, że jest on błędny, to znaczy, że musisz nad nim jeszcze popracować. Czasami ludzie z biznesu nie krytykują twojego pomysłu wprost, ale to ich niepokoi i wprowadza w błąd — wydaje się, że coś jest nie tak.
Czasami bywa też odwrotnie. W końcu znajdujesz dobry model, a podczas rozmowy z biznesem patrzą na ciebie jak na najgłupszą osobę na świecie. „Tak, masz rację, to oczywiste, ale czemu zajęło ci tyle czasu zrozumienie tych koncepcji?”. To znaczy, że wreszcie jesteś na właściwej drodze.
2. Projektuj dokładnie tyle, ile trzeba — ani więcej, ani mniej
Nadmiar i niedobór projektowania to problemy. Znalezienie równowagi między głębokim projektowaniem a samym „realizowaniem funkcji w celu osiągnięcia celu” to niebanalne zadanie. Evans daje nam kilka rad, które uważam za bardzo przydatne:
- Używaj najprostszej modelu, który rozwiązuje bieżący problem. Nie próbuj projektować rzeczywistości — nie dasz rady.
- Pamiętaj o czystości kodu. Twój kod i architektura muszą łatwo poddawać się zmianom w przyszłości. Jeśli projekt odniesie sukces, będziesz zmieniać architekturę wiele razy. Nie da się zaprojektować ideału za pierwszym razem (i prawdopodobnie nikt nie potrafi).
- Jeśli kod zaczyna „uciekać” spod twojej kontroli i widzisz, że wprowadzanie zmian staje się coraz trudniejsze, to znak, że problem leży w aktualnym modelu. Czas na refaktoryzację tej części programu.
- Refaktoryzuj małe fragmenty systemu w razie potrzeby, ponownie projektując najprostszy model, który rozwiązuje nowy problem.
- Dyskutuj. Przy kawie z programistami i architektami. Omawiaj z nimi swój problem, rób burze mózgów, wyśpij się i wracaj jeszcze raz.
- Nie dyskutuj więcej, niż trzeba. Evans zakłada wiele iteracji, krótkie dyskusje (1–1,5 godziny), uczenie się i rozmowy.
3. Zadawaj trudne pytania
Czasami pracuję nad nową funkcjonalnością i modyfikuję istniejącą, a architektura zaczyna robić się brzydka. Była całkiem niezła przed tymi zmianami, ale nagle stała się zbyt skomplikowana albo po prostu zaczęła źle wyglądać. To znak, że architekturę trzeba zmienić — nic nadzwyczajnego. Mimo to książka Evansa dała mi kilka pytań, które trzeba zadać w takich sytuacjach: Czy pominąłem coś w koncepcji dziedziny? Czy ta zmiana dodaje lub wykorzystuje koncepcję, która nie pasuje do aktualnego modelu?
Innymi słowy, zamiast dodawać kolejne if-y albo dodatkowe klasy, być może warto przemyśleć architekturę i znaleźć coś bardziej odpowiedniego albo zasadniczo innego.
4. Nie wynajduj koła.
Evans zaleca szukać zewnętrznej inspiracji kilka razy w książce. Można przeglądać katalogi wzorców, aby znaleźć coś, co da się stamtąd wykorzystać (być może z modyfikacjami). Rekomenduje też zapoznanie się z tym, jak podobne problemy rozwiązuje się w innych kontekstach (obszarach).
Co ciekawe, wiele razy zdarzało mi się pomijać to podejście. Wiele osób szuka rozwiązań w internecie — w różnych blogach, ogląda prezentacje. I prawie nigdy nie słyszę, żeby ktoś powiedział: „Przeczytałem o tym w książce XYZ”. Zwykle sesje „projektowania”, w których uczestniczyłem, były zwykłym burzeniem mózgów. A potem, po miesiącach, mogłem natrafić na przypadkową prezentację, która pokazywała inne podejście do rozwiązania naszego problemu — znacznie bardziej preferowane.
Wiele osób na konferencjach próbuje znaleźć rozwiązania w innych dziedzinach wiedzy. Szukają rozwiązań dla ogólnych problemów i próbują je dopasować do swoich specyficznych potrzeb. Ale mimo to w „życiu codziennym” bardzo często nasz horyzont nie jest zbyt szeroki i nie możemy sobie pozwolić na duże badania.
Ulepszenie, które zrobiłem osobiście w obszarze „badania problemu” — to korzystanie z bardziej uporządkowanych źródeł i przeglądanie klasycznych materiałów. Blogi i prezentacje są bardzo cenne, ale nie zrozum mnie źle: książki są lepiej uporządkowane i zawierają bardziej sprawdzone w czasie informacje. Nikt jednak nie kwestionuje „świetnych” artykułów znalezionych w zwykłym, przypadkowym wyszukiwaniu w Google. Jeśli są napisane przez ekspertów, to powinno to pasować w większości przypadków. Ale nawet eksperci nie zawsze wyjaśniają swoje rozwiązania i szczegółowo opisują problem.
Jeśli przypomnę sobie coś, co może być przydatne, wracam do źródła tych informacji, żeby odświeżyć pamięć. Staram się znaleźć powiązane artykuły, książki lub prezentacje. Jeśli nie mam pojęcia, od czego zacząć, mam kilka pomysłów, które dla mnie są użyteczne: powrót do teorii, przeglądanie katalogów (wzorców lub projektowania), skupienie się na kontekście i opisie problemu, szukanie dobrych praktyk od profesjonalistów IT w konkretnej dziedzinie.
Podsumowanie
Wszystko to jest dość oczywiste, ale radzę ci spróbować stosować to wszystko tak, „jak to rozumiesz”. Zaskoczy cię, jak wiele to zmienia.