DDD - tworzenie nowych, dużych obiektów - pytanie

Hej mam w zasadzie dwa pytania dotyczące tworzenia nowych obiektów (w nomenklaturze DDD agregatów).

1. Wiem, że agregaty powinny być projektowane jak najmniejsze i powinny być granicą dla niezmienników i modeluję one raczej pewien kontekst biznesowy aniżeli strukturę danych. Oznacza to, że zamiast Usera mamy wydzielone coś w stylu Contact, Seller, Buyer i co tam kto ma jakie domeny. Ale co z tworzeniem nowego .. no właśnie, np Usera? Jeśli mamy formatkę na froncie i podajemy tam wszystkie dane - kontaktowe, dotyczące wysyłki oraz dotyczące jeszcze innych domen - założmy z 50 różnnych pól? Gdzie wtedy taką logikę się wkłada. Tutaj w zasadzie nie operujemy na agregatach, bo my żadnego z repo nie pobieramy, więc nie ma tu pojęcia bronienia niezmienników. Pod to robi się osobny pakiet?

2. Przy tworzeniu nowego obiektu jak w pkt 1 często trzeba wykonać jakieś walidacje i poodpytywać inne moduły czy to wewnątrz jednego mikroserwisu czy inne mikroserwisy o pewne rzeczy. Wykorzystując dobre praktyki mam pewien podział modułów i wystawiam publicznie albo fasady, które udostępniają pewną logikę biznesową, albo query servicy, które zwracają dane potrzebne na front i w tych drugich jest zwykła prosta dwuwarstwowa logika. Czy z purystycznego punktu widzenia podczas tworzenia nowego obiektu powinienem tylko komunikować się z innymi fasadami czy dopuszczalne jest komunikowanie się z query servicami, jeśli akurat zwracają mi one to co potrzebuję?

Utworzenie obiektu/agregatu w jednym BC może triggerować utworzenie innych obiektów w innych BC.

Być może ciężko wskazać zalety DDD w Twojej skali, rozwazales uproszczenie architektury? Wyglada na to, ze rozwiązujesz techniczne problemy z DDD, a nie biznesowe.

Hmm akurat w tej domenie sprawdza się DDD, ponieważ wydzieliłem BC, uprościło to logikę biznesową, łatwiej się połapać w kodzie, mam lepszy podział na moduly - nie mam już czegoś takiego jak encja User.

Dlaczego uważasz, że to technniczny problem, a nie biznesowy? Wymaganie biznesowe jest zapisać to wszystko do DB na raz. Być może to rozwiązanie o którym mówisz jest najlepsze czyli zapisać jeden agregat i wyemitować eventy, które spowodują zapisanie reszty.

A pytanie odnośnie walidacji? Mogę się odpytywać o query servicy?

Wymaganie biznesowe jest zapisać to wszystko do DB na raz.

Nie, to nie jest wymaganie biznesowe. W jakim celu zapisujesz te dane?

A pytanie odnośnie walidacji? Mogę się odpytywać o query servicy?

Może lepiej na przykładzie, co chcesz walidowac?

Bambo napisał(a):

Być może to rozwiązanie o którym mówisz jest najlepsze czyli zapisać jeden agregat i wyemitować eventy, które spowodują zapisanie reszty.

Bardziej pisze jako pytający, nie odpowiadajacy, czytam i narzuca mi się pytanie, czy koniecznie chcesz generować eventy?

Bo wtedy musiałbyś (zakładając, ze masz mikroserwisy), dealowac ze stanem niespójności danych, gdy coś się nie zapisze w bazie. W celu uzyskania spójności musiałbyś pisać np. sagi.

Każdy Event powoduje to, ze oprócz odwracania kontroli ją tracisz. Wiec jak ty z tym dealujesz?

Bo wtedy musiałbyś (zakładając, ze masz mikroserwisy), dealowac ze stanem niespójności danych, gdy coś się nie zapisze w bazie. W celu uzyskania spójności musiałbyś pisać np. sagi.

Zwykle nie jest to problemem, eventy można np. zretransmitować (nie zawsze). Jest również fajny wzorzec transactional outbox. Gdyby eventy były takim wielkim problemem, to nie byłoby czegoś takiego jak Event Driven Architecture :)

@Charles_Ray:
Sprawa wygląda tak ...

1. Logujemy się przez zewnętrzny serwis (CAS).
2. Jeśli sukces to zostajemy przekierowani na nasz endpoint. Z HttpServlerRequestu wyciągamy Principala ze wszystkimi danymi o userze. Princial ten jest wsadzany do requestu w CASie. Generalnie struktura tego principala jest rozległa, tych danych idzie dużo.

Musimy zwalidować te dane Principala, które dostaliśmy.
Walidację wykonujemy odpytując się o inne moduły/mikroserwisy występujące w systemie. Część tych modułów/mikroserwisów jest mało skomplikowanymi nakładkami na DB, które są zasilane przez hurtownie ETL (z poziomu mikroserwisu nie ma zapisu do tych tabel). I tu było moje pytanie. Załóżmy, że mamy moduł, który jest nakładką na takie zasilane ETLem tabele i wystawia on jakiś QueryService, który wystawia formatki na front. Czy ja walidując tego Principala mogę się odpytać QueryServicu czy raczej powinienem przygotować jakąś fasadę w tym module, która de facto też będzie zwracać po prostu pewne dane do walidacji. To już bardziej purystyczne pytanie.

Jeśli walidacja przebiegnie ok to chcemy zapisać tego Principala do DB (zapisać nowego jeśli logowanie było po raz pierwszy bądź zupdatować istniejący rekord).

I tu się pojawią moje pytania ... No bo ten Principal jest duży i nawet jak go zmapuję sobie na jakiś obiekt domenowy typu Employee to nadal jest to wielka struktura, a ja chciałem mieć mniejsze agregaty.

Bo potem jak już wołam jakieś metody biznesowe to nie chcę operować na czymś takim jak Employee - wydzieliłem z tego sobie dobrze skrojone agregaty.