Archetypy oprogramowania zyskują na znaczeniu, bo pozwalają szybciej zrozumieć domenę i uniknąć typowych błędów projektowych. W połączeniu z Domain Driven Design stają się narzędziem, które pomaga wyznaczyć granice systemu, uprościć model i skupić wysiłek zespołu na tym, co naprawdę daje przewagę konkurencyjną. W tym artykule zobaczysz, jak archetypy działają w praktyce, kiedy mają sens i w jakich sytuacjach lepiej ich nie używać.
Archetypy i Wzorce Projektowe
Choć wielu programistów intuicyjnie porównuje archetypy do klasycznych wzorców projektowych z Gang of Four, w rozmowie DevTalk #125 bardzo wyraźnie rozdzielamy te dwa światy. Wzorce GoF są „konkretnymi wzorcami taktycznymi, wzorcami w kodzie”, stworzonymi po to, aby rozwiązać precyzyjnie określony, techniczny problem. Są powtarzalne, jednoznaczne, a ich implementację można wręcz automatycznie wykryć narzędziami typu SonarQube.
Archetypy funkcjonują zupełnie inaczej. Nie są frameworkiem ani gotowym kawałkiem kodu, który da się skopiować do projektu. To raczej sposób myślenia o modelowaniu domeny, zestaw „klocków”, z których wybiera się tylko te fragmenty, które odpowiadają realnej złożoności biznesowej. W jednym miejscu archetyp będzie miał minimalną implementację, w innym, stanie się rozbudowaną strukturą modelarską.
Krótko mówiąc:
GoF operuje na poziomie techniki. Archetypy na poziomie biznesu i architektonicznego myślenia.
To zderzenie dwóch porządków warto zobaczyć obok siebie. Dlatego poniżej znajdziesz tabelę:
| Obszar | Wzorce GoF | Archetypy |
|---|---|---|
| Poziom | konkretne wzorce taktyczne, w kodzie | sposób podejścia do modelowania na wyższym poziomie abstrakcji |
| Typ problemów | Techniczne, niskopoziomowe problemy implementacyjne | Problemy biznesowe, struktury i zachowania domenowe |
| Stosowalność | Zawsze tak samo aplikowane do tego samego typu problemów; automatycznie wykrywalne (np. przez SonarQube) | Wybór elementów zależy od złożoności i specyfiki biznesu — brak jednej implementacji |
| Charakter | Jednoznaczne, zamknięte, powtarzalne rozwiązania | Katalog „klocków modelarskich”, z których wybiera się tylko potrzebne |
| Rola w projekcie | Rozwiązywanie problemów taktycznych | Wsparcie strategicznego modelowania, granic kontekstów, agregatów i struktury domeny |
Archetypy i DDD
Choć archetypy i Domain Driven Design pochodzą z różnych tradycji, w praktyce idealnie się uzupełniają. W rozmowie DevTalk podkreślam, że oba podejścia działają na dwóch poziomach, strategicznym i taktycznym. Na poziomie strategicznym pomagają ustalić sensowny podział domeny, a na poziomie taktycznym wpływają na konkretne decyzje dotyczące agregatów, danych i procesów.
Poziom strategiczny, granice systemu i klarowność domeny
Z perspektywy DDD proces strategicznego modelowania polega przede wszystkim na znalezieniu właściwych bounded contexts. Archetypy pozwalają zrobić to szybciej, ponieważ wskazują gotowe struktury, które pojawiają się w większości firm. Jeśli w systemie występuje problem naliczania wartości (cen, punktów lojalnościowych, gigabajtów internetu) – najpewniej mamy do czynienia z archetypem pricingu. Jeśli tą wartością zarządzamy, rozliczamy ją, ma ona wielu właścicieli w różnych punktach na osi czasu – pomocny będzie archetyp accountingu. Jeśli zarządzamy użytkownikami, ich rolami lub relacjami, to klasyczny archetyp Party. Jeśli pracujemy z dostępnością lub rezerwacjami zasobów, wchodzi archetyp Inventory.
Dzięki temu nie trzeba od zera wymyślać podstawowych modeli, bo te problemy zostały rozwiązane wiele razy. Archetypy działają też jako sanity check. Pokazują, które elementy biznesu są naprawdę unikalne, a które są typową operacyjnością spotykaną w bankach, ubezpieczalniach i zwykłych sklepach. Dzięki temu łatwiej oddzielić core domain od powtarzalnych procesów.
Poziom taktyczny, agregaty, encje i konsekwencje technologiczne
Archetypy pomagają także w decyzjach kodowych. Nie są gotowym kodem, ale działają jak kierunkowskazy pokazując najczęstsze wzorce i pułapki.
Przykład Accounting
Częstym problemem jest tworzenie jednego dużego agregatu Konto, który ma listę wpisów i na jej podstawie decyduje o poprawności operacji. Taki model szybko się zapycha i nie odpowiada prawdziwej naturze domeny, ponieważ transakcja zwykle dotyczy dwóch kont. Archetyp Accounting sugeruje inne podejście. To transakcja powinna być centrum, a konto tylko kotwicą dla wpisów księgowych. Takie rozwiązanie jest prostsze i lepiej skalowalne.
Przykład Party
W przypadku archetypu Party trzeba podjąć decyzję nt granicy obiektu Party. Czy adres powinien być częścią agregatu, czy oddzielnym agregatem? To zależy od przypadków użycia. Analizie musimy poddać reguły jakie łączą oba te byty. Jeżeli zidentyfikujemy reguły wymagające natychmiastowej spójności – kompozycja adresów wewnątrz Party może okazać się lepsza. W przeciwnym wypadku, jeśli ponadto skala systemu jest duża (tzn. mamy wiele podmiotów), ich rozdzielenie będzie optymalnym rozwiązaniem.
W ten sposób archetypy pomagają unikać typowych błędów projektowych i proponują sprawdzone kierunki rozwiązań.
Kiedy archetypy to overkill
Archetypy nie nadają się do wszystkiego. Poniżej trzy konkretne przypadki, w których ich stosowanie nie ma sensu.
1. Domeny silnie techniczne
W oprogramowaniu tworzonym dla routerów sieciowych lub systemów sterowania lotem klasyczne archetypy biznesowe po prostu nie występują. W takich miejscach większą wartość ma strategiczne DDD, czyli wyznaczanie granic odpowiedzialności.
2. Praca na gotowych produktach
Jeśli pracujemy głównie na ERP, CMS lub BPMS zakupionych od dostawcy, nie mamy wpływu na bazowe modele. Archetypy nie wnoszą wtedy wartości, ponieważ model jest narzucony z zewnątrz.
3. Projekty utrzymaniowe bez planu modernizacji
W systemach legacy, w których funkcje dopisuje się metodą drobnych poprawek i obejść, wdrażanie archetypów jest nieopłacalne. Można się nimi inspirować przy drobnych zmianach, ale nie rozwiążą problemu na poziomie architektury.
Kiedy archetypy mają sens
- Gdy tworzysz custom software i masz wpływ na modelowanie
- Przy strategicznych modernizacjach i refaktoryzacjach architektury
- W greenfieldach w typowych domenach biznesowych, takich jak sprzedaż, finanse, logistyka, opieka medyczna, telekomunikacja, energetyka…i każdy inny legalny biznes
W tych obszarach archetypy pozwalają wykorzystać gotową wiedzę i uniknąć kosztownego wymyślania podstawowych rozwiązań od zera.
Jeśli chcesz więcej przykładów i kontekstu, polecam moją rozmowę z Maciejem Aniserowiczem w podcaście DevTalk: O archetypach (odc. #125).
