DevCezz

Programistyczny blog dla Ciebie

Czy zewnętrzne biblioteki w domenie to zło?
Reszta

Czy zewnętrzne biblioteki w domenie to zło?

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ł.

Przy okazji chciałbym Cię poprosić o podzielenie się Twoją opinią na temat mojego bloga. Dzięki niej będę w stanie sprawić, aby ten kawałek Internetu był lepszym miejscem. Dziękuję!

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.

Podziel się tym z innymi!

2 KOMENTARZE

  1. Cześć,
    Jednym z celów DDD jest enkapsulacja logiki biznesowej. Gdy próbujemy mieszać logikę biznesową z encjami jpa nie wygląda to faktycznie dobrze – powoduje to że mamy zbyt generyczne encje, dodatkowo zależne od struktur bazy danych. Moim zdaniem rozwiązania są dwa:
    1. Utrzymywanie osobnych modeli jpa i encji domenowych. To istny horror przy większych projektach
    2. Użycie baz nosql – wtedy można dowolny model zapisać do bazy danych i nie trzeba żadnych adnotacji z innych frameworków

    • Cześć Paweł! Dzięki za Twój komentarz. 🙂

      Ciężko się z Tobą nie zgodzić. To prawda, że encja z DDD będąca dodatkowo encją JPA staje się mocno zależna od struktury bazy danych. Rozdzielenie tego to faktycznie istny horror i karkołomność. Ciężko kogokolwiek wdrożyć w taki projekt, a potem go w nim utrzymać. Wiadomo przecież, że teraz ruchy programistów pomiędzy firmami są naprawdę spore.

      Warto pomyśleć na ten temat z biznesowego punktu widzenia. ROI może być w takim przypadku nie za duże dla takiego podejścia. Dlatego jak chce się mieć DDD i relatywnie niski próg wejścia to może warto stosować te adnotacje JPA. 🙂 Podoba mi się koncepcja NoSQL, ponieważ tam możemy uznać, że agregatem jest jeden element z kolekcji i tyle. Praktycznie jakby to podejście było szyte na miarę DDD. 🙂

      Dzięki raz jeszcze za Twoje spostrzeżenia co do wpisu. Jeszcze dodam, że w dzisiejszym świecie mikroserwisów możemy jeden z nich dosyć szybko przepisać na coś innego o ile granice są dobrze wyznaczone. Wtedy te adnotacje nie są już takie istotne. Ale to temat na osobny artykuł. 🙂

Możliwość komentowania została wyłączona.