[noarch]

W jaki sposób ukryć implementację encji w poszczególnych serwisach, jeśli jednocześnie chcemy, żeby encje mogły być w relacji z encjami z innych serwisów? Na myśl przychodzą mi tylko publiczne interfejsy, ale to raczej nie rozwiązuje problemu

[ #ddd | #oop | #java | #spring | #naukaprogramowania ]

[moriturius]

@noarch masz na myśli serwisy jak w mikroserwisach czy serwisy jak w klasy serwisowe w jednej aplikacji?
Kojarzysz co to warstwowa struktura aplikacji?

[noarch]

@moriturius: Jak w mikroserwisach. Zawsze pisałem aplikacje właśnie warstwowo, ale powoli przekonuję się do podziału bardziej domenowego, co chcę połączyć z mikroserwisami. Tylko nie wiem jak rozwiązać problem z modelem

[moriturius]

@noarch: W takim razie sprawa jest dość prosta. W każdym z serwisów powinieneś oddzielić model domenowy danego serwisu od modelu komunikacyjnego (np. danych zwracanych na endpointach, lub w klientach do innych usług). Potem trzeba tylko napisać kawałek kodu do konwertowania jednego modelu na drugi.

Niestety jest to sporo pisania ale daje Ci dużą swobodę w modyfikacji każdego modelu osobno bo konwerter zawera informację co tłumaczysz na co i jest jedynym punktem,

[noarch]

@moriturius: Oczywiście tak robię :) w każdym z pakietów dla osobnego serwisu wystawiam tylko publiczną fasadę zwracającą transfer objecty, publiczny pakiet z transfer objectami i wyjątkami.

Chodzi mi o to jak odwzorować obiektowo relacje między encjami w momencie w którym nie możesz sięgnąć bezpośrednio do encji z innego pakietu, bo jest package-private, a nie public

[moriturius]

@noarch: Jeśli jeden pakiet potrzebuje danych prywatnych drugiego pakietu to może być to jedna z takich sytuacji:
1) Prywatne dane drugiego pakietu nie są tak na prawdę prywatne i trzeba je wstawić na jakimś interfejsie komunikacyjnym
2) Coś jest nie tak z odpowiedzialnościami i/lub rzeczy są zbyt mocno podzielone. Wtedy trzeba się dobrze zastanowić nad tym co się tak na prawdę dzieje.

Dodam tylko, że ogólnie te wszystkie zasady odnośnie układania

[noarch]

@moriturius: Dziękuję za porady! :D Moje pytanie może się wydaje trywialne, ale zapewniam Cię, że nie jestem zielonym programistą (żyję z tego już jakiś czas).

Z pomocą znajomego wpadłem na trzy rozwiązania:
1) Przechowywanie w encjach jawnie samych identyfikatorów encji, z którymi dana encja pozostaje w relacji (czyli rezygnuję de facto z dobrodziejstw JPA)
2) Redundancja danych, tzn. powtórzenie modelu w miejscu, gdzie jest to potrzebne
3) jar z modelami, którego

[moriturius]

@noarch: Mam wrażenie, że to o czym piszesz w pkt. 2 to jest dokładnie to co opisałem. Trudno mi tak na prawdę doradzić coś sensownego, bo widzę, że masz jakiś konkretny problem w konkretnym projekcie i bez zobaczenia jak to jest i co właściwie stanowi problem chyba nie pomogę bardziej.

[piaskovitz]

@noarch: tez mieliśmy ten problem. U nas świetnie sprawdziło się rozwiązanie 1 tylko identyfikatory opakowane jako value objects. Co do redundancji to moim zdaniem tylko wtedy gdy jest naprawdę potrzebna z biznesowego podejścia.

[noarch]

@piaskovitz: Dzięki za info! Value Object jako Embeddable w jpa?

[noarch]

@piaskovitz: I co mi wpadło do głowy jeszcze - a możeby tak definiować relacje po nazwach tabel a nie encji, jeśli baza dla tych mikroserwisów byłaby wspólna?

[noarch]

@piaskovitz: ping