Często na konferencjach słyszymy, że w myśl DDD projektowana domena musi być “czysta”, “nieskazitelna”, “nieskalana” żadnym zewnętrznym rozwiązaniem. Najlepiej jakby opierała się tylko na standardowych bibliotekach należących do danego języka. W ten sposób przecież stajemy się niezależni od nikogo. Możemy wymienić bez najmniejszego problemu każdy dostarczony komponent z zewnątrz.

Jednak takie podejście jest czasochłonne, wymagające i czy czasem nie jest sztuką dla sztuki? Sam byłem w tym miejscu i zamiast ruszyć z kopyta z implementacją utykałem na samym początku projektu zastanawiając się jak wyciąć Hibernate z mojej domeny. Dni mijały, a poziom irytacji wzrastał. Oglądałem tutorial za tutorialem, aby odnaleźć ten upragniony Święty Graal. Aż w końcu odpuszczałem, projekt zamykałem, a sam udawałem się na odpoczynek w oczekiwaniu na kolejny świetny pomysł.

Pętla została przerwana

Dopiero po jakimś czasie dotarło do mnie, że to nie tędy droga. Stało się to za sprawą prezentacji Łukasza Szydło na temat DDD w systemach rozproszonych. “Wszyscy chodzą na skróty” - to zdanie zaczęło we mnie rezonować. Dzięki niemu zastanowiłem się nad tym co ja właściwie chcę osiągnąć swoim podejściem. Czy czasem mój wewnętrzny purysta językowy nie za bardzo daje o sobie znać? Bo przecież my jako programiści mamy najczęściej za zadanie po prostu rozwiązać dany problem biznesowy i to możliwe jak najszybciej.

Z swoich rozważań doszedłem do wniosku, że na samym początku projektu trzeba poczynić jakieś założenia co do niego. Należy zastanowić się nad celem jego powstania, jaki dokładnie problem ma on rozwiązać. Czy ma być to aplikacja webowa czy mobilna, czy o długim cyklu życia czy jednak o krótkim. Następnie można przejść do decyzji technologicznych. Skoro ma być to aplikacja webowa to może warto całą domenę oprzeć na Spring Boot? Bo przecież czy zdarzyło Ci się być na projekcie, który nagle wymienił bebechy i przeszedł ze Springa na Quarkusa? Nie jest to niemożliwe, ale raczej bardzo mało prawdopodobne. Więc czy w domenie naprawdę będą Ci przeszkadzały adnotacje zewnętrznego frameworka? Przecież on raczej zostanie z Tobą do końca, a przez próbę jego sztucznego oddzielenia wprowadzi się tylko zamieszanie do kodu.

Spring może stać się fundamentem, na którym zbudujesz system zarządzający np. płatnościami. Jeśli natomiast dobrze rozdzielisz moduły biznesowe to wyrzucenie jednego z nich i zastąpienie go nowym rozwiązaniem stojącym na np. Node.js nie będzie relatywnie dużym kosztem. Oczywiście niektóre elementy warto wydzielić z domeny i schować za abstrakcją, aby można je było łatwo zastąpić. Jednak coś trzeba przyjąć za pewnik i na tym budować swoją aplikację.

Podsumowanie

Powyższy tekst oparłem na swoich doświadczeniach, ale w Internecie także możemy znaleźć różne artykuły na ten temat. Vladimir Khorikov podaje heurystyki uzależniania domeny od zewnętrznych bibliotek. Z kolei użytkownik ArwynFr na StackOverflow napisał, że domena jest “czysta” jeśli nie zależy od warstwy infrastruktury albo prezentacji. Jeśli coś jest kluczowe dla biznesu to może znaleźć się blisko rdzenia aplikacji. Czytając jeszcze opinię użytkownika Flater na StackExchange dowiemy się, że… to zależy. Jeśli coś jest łatwe do schowania za abstrakcją to można się o taki zabieg pokusić. W innym przypadku nie ma co się nad tym zbytnio skupiać i po prostu robić swoje.

Według mnie biblioteka Apache Commons dostarczająca StringUtils także nie powinna być problemem. Ułatwia ona pisanie kodu, przez co nie trzeba się skupiać na detalach jak sprawdzenie czy String na pewno jest pusty. To samo tyczy się np. Lomboka.

Należy mieć świadomość narzędzi jakie wrzucamy do naszej domeny. Trzeba wiedzieć jakie wnoszą one korzyści, ale również jakie niosą ze sobą negatywne konsekwencje. Najważniejsze jest jednak, aby robić swoje i nie tkwić w martwym punkcie, bo to donikąd nie prowadzi.