Modelowanie Domeny (DDD), a ORM i inne zewnętrzne biblioteki

Question

cześć! Staram się wdrożyć od jakiegoś czasu w techniki modelowania domenowego, chce w końcu przestać patrzeć na aplikacje przez pryzmat bazy. Oczywiście wiem, że DDD jest dla bardziej zaawansowanych przypadków niż zwykła przeglądanie bazy , do tego starczy CRUD, nie w tym rzecz.

Chce tu zadać pytanie, które mnie trapi. Cięzki mi znazleźć konkretną odpowiedź w internecie. Projekty na githubie, które przeglądałem kłócą się z tym co mówią pryncypia.

Załóżmy, że opieram aplikacje o framework, dajmy na to Symfony albo Laravel, cokolwiek. Ewentualnie robie bez FW ale używam Doctrine'a.
Pytanie dotyczy "encji" ORM'owej. Gdzie takowa klasa powinna być przechowywana?Czy jej miejsce jest w domenie (jak pokazują przykłady z hub;a), czy może obok repozytorium na warstwie infrastruktury? A możę jeszcze gdzieś indziej?
Jednak taka encja z doctrine'a ma adnotacje itd. więc niejako pojawia się nam wtedy zależność do zewnętrznej biblioteki.

Answer 1

 kłócą się z tym co mówią pryncypia.
 

bo wiele osób, przez brak znajomości DDD, próbuje zrobić coś po swojemu, tak to PRYNCYPIA się nie kłócą :) 

  "encji" ORM'owej.

Przechowywane encje są w bazie zarówno w DDD, jak i normalnej aplikacji nie opartej na DDD, problem w tym, że ENCJA W DDD- nie jest tym samym co encja w klasycznej aplikacji RESTOWEJ :) 

Encja w takim CRUD prostym- to po prostu obiekt bazodanowy reprezentujący TABELE... natomiast w nomenkluaturze DDD, taka encja to : 
Encja (ang. Entity) to obiekt reprezentujący dane. Według Erica Evansa musi posiadać swoją tożsamość. To oznacza, że musi mieć jakąś wartość, która ją wyróżnia. 

To wclanie o oznacza że jest to TABELA W BAZIE 1-DO-1  :) , co wazne i. Jedna encja powinna dotyczyć jednej rzeczy/jednostki. Może ona zawierać różne dane, relacje do innych encji oraz Value Object.

Różnica jest taka że encja DDD, może posiadać zachowanie( własne metody dodatkowe, które coś realizują na jej rzecz)  którego nie powinny posiadać ENCJE ORM-OWE  w klasycznym CRUD. 

Comments

Dziękuję za odpowiedź. Niestety nie odpowiedziałeś na moje pytanie. Znałem rożnice między klasą generowaną przez orm tzw. encją lub modelem w zależności od ORM'a, a tą faktyczną prawdziwą encją w kontekscie DDD.

 
Chodzi mi jedynie o to, gdzie taka encja ORM'a powinna się znajdować.
Skoro kontaktujemy się z ORM'em poprzez Adapter na warstwie infrastruktury, który implementuje port z warstwy domeny to gdzie powinna znajdować się klasa generowana przez ten ORM czyli ta "encja". Również na infrastrukturze skoro dotyczy obcego bytu czy może w domenie?

 

Dodatkowo chciałem jeszcze dopytać o porty wejściowe.
Np. Controllery restowe, jak rozumiem powinniśmy go w DDD potraktować jako Adapter, który z warstwy infrastruktury powinien kontaktować się w dół z rdzeniem naszej aplikacji.
Tutaj nasuwa się pytanie kolejne - czy Adapter może bezpośrednio dowoływać się do warstwy Domeny?  Według https://youtu.be/D1vcLp4ZEYc?t=1936
Może, klasa repozytorium adaptująca port znajduje się na warstwie infrastruktury i jak widzimy wypluwa nam od razu gotowy obiekt Domenowy.

Czyli zakładam, że cały algorytm Tworzenia / Pobierania obiektów znajduje się właśnie w repozytorium.
Kompletujmy dane, następnie przekazujemy je do Agregatu - w przypadku filmiku to ProductDemand, wewnętrzne reguły biznesowe sprawdzą czy może się on utworzyć i zwróci go.