Warstwa domeny a aplikacji

Cześć, ostatnio spotykam się z różnym podejściem do określania co należy do warstwy domeny, a do warstwy aplikacji.

Tu https://www.baeldung.com/hexagonal-architecture-ddd-spring autor pisze, że u niego wszystko co jest corem i może być użyte w jakimkolwiek środowisku należy do domeny, a do warstwy aplkacji w apce RESTowej należą RestControllery. Czyli jak rozumiem gdyby zamiast RESTa był jakiś Swing to w warstwie Aplikacji byłby właśnie Swing (całe GUI i integracja z domeną) ?

Spotykałem się też z innym podejściem, gdzie do warstwy aplikacji należą fasady + obsługa transakcji i security + jakieś dtosy wychodzące z fasady, a domena to encje, fabryki, repozytoria, polityki i w sumie wszystko to co fasada używa pod spodem.

W sumie z transakcjami mam problem gdzie umieścić - bo z jednej strony jest to kwestia typowo technologiczna i do użycia z SQL, a z drugiej strony jeśli wiemy, że nie mamy wsparcia transakcji, bo mamy inną technologię to też inaczej napiszemy całą domenę.

Pozdr.

Bambo napisał(a):

Tu https://www.baeldung.com/hexagonal-architecture-ddd-spring autor pisze, że u niego wszystko co jest corem i może być użyte w jakimkolwiek środowisku należy do domeny, a do warstwy aplkacji w apce RESTowej należą np RestControllery. Czyli jak rozumiem gdyby zamiast RESTa był jakiś Swing to w warstwie Aplikacji byłby właśnie Swing (całe GUI i integracja z domeną) ?

Ja bym bardziej powiedział że REST, HTML i Swing to warstwa prezentacjia (co prawda w przypadku RESTa bardzo cieńka, ale nadal)

Spotykałem się też z innym podejściem, gdzie do warstwy aplikacji należą fasady + obsługa transakcji i security + jakieś dtosy wychodzące z fasady, a domena to encje, fabryki, repozytoria, polityki i w sumie wszystko to co fasada używa pod spodem.

Interfejsy repozytoriów. Implementacje repozytoriów są w warstwie infrastruktury

@KamilAdam:
Interfejs repozytorium w warstwie infry o_O? Przecież to jest port - jest to związane z domeną. Jak wymieniasz technologie to zmieniasz infrę, ale interfejsu repo nie zmieniasz, bo ten kontrakt to właśnie logika Twojej apki. https://blog.allegro.tech/2020/05/hexagonal-architecture-by-example.html
Implementacja owszem, w warstwie infry, bo to już adapter.

Albo inaczej .. co byś wstawił do wartswy aplikacji?

Niewiele, bo to cienki warstwa. Głównie na security, "cieknące" tranzakcje, i ewentualnie logowanie wszystkiego co wchodzi do aplikacji i wychodzi.
IMHO jak skleisz warstwę aplikacji z warstwą domenową to duże wypaczenie się nie stanie (oprócz tego że nastąpi gwałt na architekturze 4 warstwowej i będziesz mieć architekturę 3 warstową)

BTW Teoretycznie warstwę domenową dalej można dzielić na warstwę stanową i bezstanową (funkcyjną). Wtedy nie mamy clean architecture tylko 5 warstwową pure architecture, ale jeszcze tego nie widziałem w prawdziwym projekcie :)

Transakcje mogą też być zaimplementowane przez wzorzec CQRS i wtedy są na poziomie infrastruktury (przynajmniej tak mi się wydaje :p)

A obsługi transakcji w domenie nie można np. bezinwazyjnie zapewnić przez AOP?

Bezinwazyjnie, AoP - pick one ;)

Dla mnie domena to jest wszystko co jest związane z "biznesem" aplikacji, a warstwa aplikacji to są technikalia takie jak zewnętrzne interfejsy (REST, SOAP, WS, frameworki, baza danych itd). Przy czym domena będzie mieć w sobie pewne interfejsy, które implementują elementy "aplikacji", np. domena używa jakiegoś repozytorium, a to że ono jest zaimplementowane w taki czy inny sposób to juz technikalia.
Można by pewnie też patrzeć na to na zasadzie: warstwa aplikacji to są rzeczy które mógłbyś wymienić na inne, gdybyś tylko chciał, bez ruszania domeny. Np. podmieniasz sobie springa na jee.

No właśnie i wychodzi na to, że każdy to rozumie inaczej.
Dla mnie domena to jest coś co wrzucę do osobnego modułu mavenowego, nie mam żadnych zewnętrznych zależności i mogę tego użyć stosoując jakąkolwiek formę prezentacji (REST + jakiś react, Swing bądź nawet konsola) oraz jakiekolwiek technikalia implementujące moje interfejsy domenowe (czyli łatwo podmienię sobie JPA na JOOQ albo nawet użyję Mongo lub bazę zrobionę na systemie plików).

Warstwa infry to właśnie wszystko związane z implementacjami repo, jakieś serwisy uderzające do innych usług (czyli po prostu http clienty) i implementacje publisherów (wykorzystujące pod spodem rabita czy kafke) itd.

Warstwa prezentacji to właśnie jakiś Swing, RestControllery albo nawet konsola.

Warstwa aplikacji to natomiast cienka warstwa pozwalające zintegrować warstwę prezentacji i warstwę domeny. I często ta warstwa aplikacja jest scalona z warstwą domeny bo zazwyczaj mamy po prostu 1 serwis, a nie 2 osobne. Ale gdyby czystą domenę wrzucić do modułu mavenowego, to będziemy mieć tam na wejściu jakieś np TaskFadace czyste od jakichkolwiek transakcji, security i nie wiem .. logowania. I w takim przypadku jak już wybierzemy nas zstos technologiczny (np psql, spring, rabbit itd) to piszemy sobie w warstwie aplikacji TaskApplicationService, do którego wstrzykujemy nasz TaskFacade i dodajemy transakcje, security, jakieś wywołanie serwisów logujących i inne bajery. Imo taki serwis aplikacyjny będzie się trochę różnił w zalężnosci od warstwy prezentacji lub wybranych technikaliów. Jest to dla mnie po prostu spięcie domeny z warstwą prezentacji uwzględniając resztę świata czyli frameworki i technikalia.

Ja tak to rozumiem ;p

Brakuje Ci warstwy, która różnie się nazywa - serwisy aplikacyjne, fasady, use case’y. To na tej warstwie zakładane są transakcje. Warstwa jest maksymalnie cienka, zawiera kod proceduralny i jej zadaniem jest wystawianie dla świata zewnetrznego funkcji systemowych i przekazywanie sterowania do domeny.

W momencie, kiedy wołasz z kontrolera od razu serwis domenowy, albo pobierasz agregat z repozytorium, faktycznie nie wiadomo, gdzie założyć transakcje, gdzie jest unit of work.

Koncepcję dość dobrze opisuje Verhnon w „czerwonej książce”.

Co jest domeną? Core domain to główny powód, dla którego budujesz system - kluczowe dla biznesu reguły biznesowe. W teorii powinieneś ją zakodować to w czystej Javie bez jakichkolwiek zależności do Kafki, HTTP, Swinga, etc. W praktyce osobiście wyciągam z tego co ma dla mnie największa wartość, czyli testowalność poprzez zastosowanie dependency inversion principle - zależności techniczne chowasz za interfejsem (zwanym w kręgach sekciarskich DDD portem). W rozbudowanej domenie i tak jest się ciężko połapać (niestety naćkanie fabryk i polityk nie za bardzo pomaga albo ja nie umiem), wiec w tym aspekcie największy uzysk widzę po prostu z czystego kodu, modularyzacji i testów.

Dla mnie domena to jest coś co wrzucę do osobnego modułu mavenowego, nie mam żadnych zewnętrznych zależności

@Bambo co masz na myśli pisząc żadnych zewnętrznych zależności? Zakładam że chodzi o zależności typu implementacja repozytoriów, frameworki itp.
Bo jednak bez Junita czy jakiś loggerów to ciężko napisać sensowną implementację domeny.

O jakiej aplikacji mówimy? Bo to będzie definiować jak daną aplikację i jej poszczególne elementy wchodzące w skład podzielić i wyznaczyć. Śmiem twierdzić że pochodzenie danych nawet ma znaczenie (od użytkownika, ze storage, wyliczane wewnątrz aplikacji, z czujników, a może ktoś nam je napycha?).