Ostatnio zainteresowałem się DDD oraz CQRS i postanowiłem spróbować zastosować te rozwiązania do prostej, crudowej apki typu to-do list.
W pakiecie core mam: klasę Task, która reprezentuje zadanie do zrobienia, 2 interfejsy repozytorium - jeden TaskQueryRepository (metody getAll i getById) i drugi TaskCommandRepository (metody add, update i delete) oraz 2 serwisy jeden TaskQueryService i drugi TaskCommandService, korzystające z adekwatnych repo.
W pakiecie framework mam springowe rest api rozbite na 2 controllery TaskQueryApi i TaskCommandApi.
I tutaj zaczynają się schodzić. Zgodnie z zasadami czystej architektury chciałem, żeby apka była jak w najmniejszym stopniu zależna od frameworka, dlatego zrezygnowałem ze springowego kontenera IoC (oglądałem trochę konferencji @jarekr000000) i w tych controllerach zainicjowałem wszystko przez "new".Przy inicjowaniu serwisów pojawia się problem z repo Spring Data JPA. Spring sam sobie go tworzy i nie udostępnia tej klasy, przez co nie mogę sam stworzyć nowego obiektu. Rozwiązaniem okazał się Hibernatem, ale chciałbym korzystać jednak ze Spring Data JPA albo czegoś podobnego. Co o tym wszystkim sądzicie?
- Nie polecam Spring Data JPA. Ze szczególnym uwzględnieniem JPA - straszna qpa.
Wymień to na JOOQ albo JDBI i wiele problemów Ci zniknie (nawet jeśli korzystać będziesz ze Springa). - Formalnie możesz użyć
JpaRepositoryFactoryze spring data jpa i wywołać metodęgetRepositorypodając klasę swojego interfejsu - wtedy ma szansę Ci zadziałać tworzeniemanualneobiektu repository. Ma szansę - ale jest z tym związane dużo niuansów, transakcje itp. możesz stracić dużo czasu, a nie wiem czy warto.
Napisze tak: dogmatyzm < pragmatyzm. Użyj interfejsów Spring Data jako porty w domenie, jeszcze żaden inżynier ani purysta DDD od tego nie umarł. Jak jesteś purystą, to owrappuj interfejsy Spring Data we własne klasy, które będą żyły w adapterach - sztuka dla sztuki IMO.
Polecam prezki Łukasza Szydło, spoko podejście podparte doświadczeniem:
@Edelner:
Czemu findById masz w query repo? Jesli zapytanie o encje służy wykonaniu logiki biznesowej to powinno w być Command Repo. Jeśli masz np wymaganie, że musisz też mieć unikalny name Taska to pewnie też tam się znajdzie findByName.
W części query najczęściej masz inne modele, bardziej rozbudowane jeśli chodzi o ilość pół i płaskie (prymitywy zamiast obiektów wartości). Część query posiada mniej warstw samej architektury, a zamiast repo masz dao i metody skrojone pod front czy inne prezentacje a nie pod logikę biznesową. W przypadku używania Spring Data wygląda to praktycznie tak samo, bo encje jpa to najczęściej encje domenowe, ale przecież repozytoria mogą zwracać obiekty biznesowe, które są budowane po częśći z DB, a po części z innych źródeł jak jakieś pliki czy też zewnętrzne serwisy.
czy na 100 procent rozumiesz co tu się dzieje? Jak tak, to jedziesz dalej, jak nie, to poczekaj i czytaj.