Odseparowanie modelu danych od modelu domenowego

Nie znam, pewnie jakbym poszukał to bym coś wartościowego znalazł ale nie mam zbytnio czasu. Jak ci zależy to poszukaj i wrzuć linki do repo tutaj - ocenimy.

Pytanie moje jest inne, po co ci ten osobny model? Jaki problem próbujesz rozwiązać? Czy chcesz zaspokoić swoją ciekawość i poznać taką architekturę aby w przyszłości ją kiedyś wykorzystać, czy chcesz jej użyć w swoim projekcie?

Jeśli to pierwsze to spoko - baw i ucz się. Jeśli drugie napisz konkretnie w czym ten osobny model miałby ci pomóc i jaki problem w twoim projekcie miałby rozwiązać.

Osobiście takie podejście zastosowałem w komercyjnym projekcie tylko raz, gdy pewien moduł, który robiliśmy, miał logikę, której nie dało się łatwo zamodelować w klasyczny sposób mapując tabele z bazy danych na encje biznesowe, a nie mieliśmy możliwości użycia bazy nierelacyjnej, która by bardziej pasowała plus nie chcieliśmy kisić logiki w serwajsach, tylko mieć Ricz Domejn Model.

Albo inaczej, nie chcieliśmy wprowadzać drugiej bazy, żeby nie dodawać sobie nowych problemów związanych z synchronizacją danych, spójnością i tego typu rzeczami. Dlatego zrobiliśmy dwa modele i nawet to działało. Ale co ważne takie rozwiązanie występowało tylko w tym jednym module/kontekście biznesowym. Gdyby cała aplikacja była zaprojektowana i napisana w sposób, który wymuszałby stosowanie dwóch osobnych modeli wszędzie w każdym module/kontekście, to byłby to dramat, taka sztuka dla sztuki. Niby można by tak zrobić całą aplikację, tylko po co? Jak w pozostałych modułach to byłoby w większości mapowanie z Customer.Name na CustomerEntity.Name

I to jedyny powód dla którego rozważałbym dwa modele, czyli sytuacja, gdy mechanizm persystencji ma inny model niż wynika to z logiki biznesowej. Do całej reszty wystarczy model domenowy mapowany za pomocą konfiguracji ORM-a na tabele w bazie danych.

lukascode napisał(a):

Czy znacie może jakieś przykładowe repozytoria na github gdzie zastosowano architekturę, o której rozmawiamy tj. z odseparowanym modelem domenowym i persystencji?
Najlepiej żeby to nie było e-commerce.
Jak już chcę wzorować się na czymś co jest zgodne ze sztuką i całym ddd.

Nie znam takiego czegoś niestety, niestety raczej projekty DDD są projektami komercyjnymi z zamkniętym kodem, ale myśle że na tym kanale znajdziesz wiele sensownych informacji:

Pytanie moje jest inne, po co ci ten osobny model? Jaki problem próbujesz rozwiązać? Czy chcesz zaspokoić swoją ciekawość i poznać taką architekturę aby w przyszłości ją kiedyś wykorzystać, czy chcesz jej użyć w swoim projekcie?
Jeśli to pierwsze to spoko - baw i ucz się. Jeśli drugie napisz konkretnie w czym ten osobny model miałby ci pomóc i jaki problem w twoim projekcie miałby rozwiązać.

@markone_dev Używam w swoim prywatnym projekcie. Generalnie założyłem, że model trzeba przemyśleć za wczasu a nie, że robimy wszystko na encjach w hibernate
a później się okaże, że trzeba to odwracać bo jednak potrzebujemy rich domain model. Czy nie powinno się być tutaj spójnym, żeby jednak ten model domenowy
był spójny we wszystkich kontekstach?

Gdyby cała aplikacja była zaprojektowana i napisana w sposób, który wymuszałby stosowanie dwóch osobnych modeli wszędzie w każdym module/kontekście, to byłby to dramat, taka sztuka dla sztuki. Niby można by tak zrobić całą aplikację, tylko po co? Jak w pozostałych modułach to byłoby w większości mapowanie z Customer.Name na CustomerEntity.Name
I to jedyny powód dla którego rozważałbym dwa modele, czyli sytuacja, gdy mechanizm persystencji ma inny model niż wynika to z logiki biznesowej. Do całej reszty wystarczy model domenowy mapowany za pomocą konfiguracji ORM-a na tabele w bazie danych.

Czy to nie kłóci się z tym co pisał @somekind, że mamy później leaky abstraction?

Aleksander-32 napisał(a):

lukascode napisał(a):

Czy znacie może jakieś przykładowe repozytoria na github gdzie zastosowano architekturę, o której rozmawiamy tj. z odseparowanym modelem domenowym i persystencji?
Najlepiej żeby to nie było e-commerce.
Jak już chcę wzorować się na czymś co jest zgodne ze sztuką i całym ddd.

Nie znam takiego czegoś niestety, niestety raczej projekty DDD są projektami komercyjnymi z zamkniętym kodem, ale myśle że na tym kanale znajdziesz wiele sensownych informacji:

Obejrzałem ale nie trafia to do mnie, za dużo teorii. Wolałbym coś praktycznego zobaczyć.

lukascode napisał(a):

Czy to nie kłóci się z tym co pisał @somekind, że mamy później leaky abstraction?

Jeśli masz ORMa, który pozwala Ci mapować encje biznesowe i nie ma wobec nich jakichś głupich wymagań, typu muszą być oznaczone jakimiś atrybutami, dziedziczyć z klasy ORMa, to nie.

lukascode napisał(a):

Generalnie założyłem, że model trzeba przemyśleć za wczasu

Cechą modelu biznesowego jest to że będzie się zmieniał z czasem.

a nie, że robimy wszystko na encjach w hibernate
a później się okaże, że trzeba to odwracać bo jednak potrzebujemy rich domain model.

Tutaj musimy wrócić do podstaw DDD. W DDD wyróżniamy następujące poddziedziny:

• Główna (Core Subdomain)
• Wspierająca (Supporting Subdomain)
• Generyczna (Generic Subdomain)
  Szczegółowy opis można znaleźć w Google oraz książkach Evansa i Vernona, ja tylko napiszę, że poddziedzina główna to serce systemu. Implementacja tej poddziedziny świadczy o konkurencyjności przedsiębiorstwa i to implementacja tej dziedziny wymaga dokładnego planowania i analizy. Dlatego do implementacji poddziedziny będziesz chciał zaangażować najlepszych ludzi i spędzić dużo czasu na jej odpowiednim modelowaniu.

I teraz wracając do zmienności modelu biznesowego w czasie, może okazać się, że to właśnie w dziedzinie głównej będziemy chcieli zachować separację modelu biznesowego od warstwy persystencji, bo nie chcemy aby jakieś szczegóły związane z silnikiem bazy danych zaśmiecały nam model i utrudniały jego rozwój.

Z kolei w poddziedzinach wspierających, szczególnie takich w których za wiele się nie dzieje pod kątem zmian, nie widzę problemu aby mapować encje JPA bezpośrednio na tabele w bazie danych.

A do poddziedzin generycznych to się kupuje gotowe rozwiązania na rynku i integruje z resztą poddziedzin.

lukascode napisał(a):

Czy nie powinno się być tutaj spójnym, żeby jednak ten model domenowy
był spójny we wszystkich kontekstach?

Tego nie rozumiem. W jakim sensie spójny?

lukascode napisał(a):

Gdyby cała aplikacja była zaprojektowana i napisana w sposób, który wymuszałby stosowanie dwóch osobnych modeli wszędzie w każdym module/kontekście, to byłby to dramat, taka sztuka dla sztuki. Niby można by tak zrobić całą aplikację, tylko po co? Jak w pozostałych modułach to byłoby w większości mapowanie z Customer.Name na CustomerEntity.Name
I to jedyny powód dla którego rozważałbym dwa modele, czyli sytuacja, gdy mechanizm persystencji ma inny model niż wynika to z logiki biznesowej. Do całej reszty wystarczy model domenowy mapowany za pomocą konfiguracji ORM-a na tabele w bazie danych.

Czy to nie kłóci się z tym co pisał @somekind, że mamy później leaky abstraction?

Patrz punkt wyżej o typach podziedzin w DDD. Nie każda poddziedzina musi być idealnie czysta z pierdyliardem abstrakcji. Czasem trzeba po prostu zrobić CRUDa i nie potrzebujemy tu DDD, wystarczy zwykła architektura encja-serwis i gotowe.

Patrz punkt wyżej o typach podziedzin w DDD. Nie każda poddziedzina musi być idealnie czysta z pierdyliardem abstrakcji. Czasem trzeba po prostu zrobić CRUDa i nie potrzebujemy tu DDD, wystarczy zwykła architektura encja-serwis i gotowe.

Tu się zgadzam - jak masz jakies tam API od rejestracji użytkowników to jakieś potężne DDD nie jest potrzebne

I to jedyny powód dla którego rozważałbym dwa modele, czyli sytuacja, gdy mechanizm persystencji ma inny model niż wynika to z logiki biznesowej. Do całej reszty wystarczy model domenowy mapowany za pomocą konfiguracji ORM-a na tabele w bazie danych.

Co do mapowania za pomoca ORM - ORM wymusza pewne ograniczenia, np. w przypadku JPA setteroze, konstruktor bez argumentów etc więc na pewno nie używałbym to jeśli chcemy mieć rich domain model, ale oczywiście - czasem wystarczy

Aleksander-32 napisał(a):

Co do mapowania za pomoca ORM - ORM wymusza pewne ograniczenia, np. w przypadku JPA setteroze, konstruktor bez argumentów etc więc na pewno nie używałbym to jeśli chcemy mieć rich domain model, ale oczywiście - czasem wystarczy

Dokładnie tak.

Mój wywód tyczył się tego jak rozpoznać kiedy i gdzie warto stosować Rich Domain Model, co jest dość trudne, ale strategiczne DDD tu przychodzi na ratunek i daje wskazówki, gdzie taki model ma najwięcej sensu. Zazwyczaj będzie to poddziedzina główna, ale czasem zdarza się, że w niektórych poddziedzinach wspierających też opłaca się zastosować RDM, zwłaszcza w sytuacjach, gdy z pewnych względów nie da się łatwo zamodelować logiki w oparciu o encje JPA, albo szczegóły implementacyjne frameworka/silnika bazy danych będą utrudniać implementację i późniejszy rozwój modelu dziedzinowego.