Na początek krótki wstęp historyczny: od przeszło dwóch lat jestem Java Backend deweloperem. Na początek trafiłem do projektu którego architektura była opisana wzorcem: CSR – czyli Controller/Service/Repository in one object, znana szerzej jako „architektura studencka”. Niestety wzorzec ten trudno było modyfikować i utrzymywać stąd też następnym krokiem było przepisanie aplikacji na architekturę warstwową. Szczęście moje nie trwało długo ponieważ po pewnym czasie projekt dramatycznie zaczął puchnąć w związku z nowymi funkcjonalnościami. Jako rozwiązanie postanowiłem połączyć podejście DDD (w związku z tym że proces biznesowe były coraz to trudniejsze do zrozumienia gdy były opisane przez gettery i settery i po jakimś czasie trudno było w łatwy sposób je rozszyfrować co robią) oraz architekturę heksagonalną która, wydaje mi się, ładnie pakuje moduł (bounded context) aplikacji. Jak postanowiłem tak zrobiłem czego rezultatem jest poniższy projekt przykładowy:
https://github.com/matadini/sysmusic
Podczas jego pisania pojawiło się kilka pytań na które, mam nadzieje :) udzielicie mi odpowiedzi:
• Czy obiekty domenowe tj. dane + metody biznesowe – w prostym rozumieniu można rozumieć jako encje JPA bez getterów i setterów, którego stan zmieniamy za pomocą dedykowanych metod biznesowych?
• Czy w przypadku bounded contextów tylko agregat posiada swoje repozytorium (połączenie do bazy) a wszelkie inne relacje są wstawiane do bazy kaskadowo?
• Czy to normalna sytuacja w której to w dwóch kontekstach mam dwie encje odnoszące się do tej samej tabeli w bazie? I czy może być ich więcej? Jak sobie radzić z not nullami jeżeli możemy mieć kilka encji do jednej tabeli.
• Czy w przypadku bounded contextu / modułu testujemy tylko serwis aplikacyjny który wystawiamy na świat zewnętrzny?
• Czy utrzymujecie w swoich projektach commona który przechowuje wszystkie DTO latające po HTTP / interfejsy RMI i klasy przesyłowe, które są kontraktem?
• Czy pisząc RESTowy serwis praktykujecie pisanie do nich dedykowanych klientów które trafiają na waszego firmowego nexusa mavenowego/gradlowego? Widziałem takie podejście w przypadku korzystania GCP i chciałbym u siebie w firmie to przeforsować.
• Jak wyglądają u was testy integracyjne? Pisząc serwis restowy + klienta nie widzę sensu pchania mojego serwera do innych testów skoro przetestowałem serwis i klienta po którym inni będą się ze mną integrować.
• Wracając do obiektów domenowych i modułów z heksagonu: w którymś Microsoftowym podręczniku czytałem że warstwie domeny nie powinno być absolutnie żadnej informacji na temat infrastruktury/frameworka ORM – a w moim podejściu jest, jak to się robi w waszych projektach?
• Jak wygląda u was testowanie z użyciem bazy w pamięci? Mockujecie repozytoria czy tak jak u mnie, stawiacie na każdy test czystą bazę H2? Niestety moje podejście wydłuża czas testów przez co chciałbym się dowiedzieć jak robi to szybciej.
Będę niezmiernie wdzięczny za wszelkie wskazówki i odpowiedzi dotyczące powyższego projektu. Wspomnę jedynie że tylko moduł BAND można uznać za względnie skończony.