DDD Kiedy należy utworzyć obiekt domeny i obiekt trwałości zamiast używać obiektu trwałości jako obiektu domeny?

Question

Kiedy pracuję z moim rozumieniem Domain Driven Design, stwierdzam, że mam regułę, która wydaje się działać, chociaż chciałbym zobaczyć, czy jest ona przesadna, a także chciałaby zobaczyć inne perspektywy tej samej sytuacji.

Moje pytanie brzmi następująco: "Kiedy model domeny i model trwałości powinny znajdować się w osobnych obiektach?" Moim językiem z wyboru jest obecnie Java i korzystam z modelu repozytorium Spring Data.

Widzę trzy główne odpowiedzi na moje pytanie.

1. Zawsze używaj oddzielnych obiektów domeny z obiektów trwałości.
2. Używaj oddzielnych obiektów domeny tylko wtedy, gdy umieszczanie metod domenowych (zachowań) na obiektach trwałości jest niepraktyczne.
3. Użyj obiektów trwałości jako obiektów domeny we wszystkich przypadkach.

W celu zadawania pytań na temat DDD stwierdzam, że muszę użyć przykładowego kontekstu ograniczonego, ponieważ nie wiem jeszcze wystarczająco dużo o DDD, aby zadać bardziej abstrakcyjny sposób.

Oto moja ilustracyjny ograniczony kontekst: że mam system Kodyfikacyjnej Prawa z następującymi zasadami działalności:

1. Każda ustawa o księgach musi być sklasyfikowany.
2. Każde prawo ma identyfikator składający się z dwóch części, prefiksu numeru kodyfikacji i sufiksu koalonacji kodyfikacji. (Przykład: 100-0100, 599-2030).
3. Istnieje wiele jurysdykcji prawnych, które korzystają z systemu kodyfikacji prawa i powinny być w stanie tworzyć własne koalicje, ale prefiksy kodyfikacji mają charakter globalny i muszą być takie same we wszystkich jurysdykcjach, aby ułatwić ogólną porównywalność.
4. prefiksy numerów kodyfikacyjnych są pogrupowane w szerokie kategorie kodyfikacji. Kategorie ujednolicenie mieć zakres, na przykład numer 100-199, 200-299, 700-799, itp

Wyrażając to ograniczone kontekście jako model trwałości I mają następujące:

table: codification 
fields: chart_code, prefix, coassign, codification_category 

table: codification_chart 
fields: chart_code, jurisdiction_description 

table: codification_category 
fields: category, low_category_number, high_category_number, description 

table: global_codification 
fields: prefix, coassign, codification_category 

Wiem, że powinienem zacząć od modelu domeny. Mam modelu Trwałość i model domeny

w moim modelu domeny mam trzy domeny obiektów

public Codification { 
    private String prefix, coassign; 
    codificationCategory codificationCaegory; // an enum type 
    public Codification(...) { // set private vars } 
    // getters for private variables 
} 

public CodificationChart { 
    private List<Codification> chartCodifications = new ArrayList<>(); 
    private String chartCode; 
    // public constructor to initialize private variables 
    // getters for private variables 
    public Codification addCodificationToChart(Codification){...} 
    public void removeCodificationFromChart(Codification){...} 
    public boolean checkCodificationInChart(Codification){...} 
} 

public enum CodificationCategory { 
    CIVIL, CRIMINAL, PROPERTY, CORPORATE, FAMILY, CONSUMER, ETHICS, BANKRUPTCY; 
} 

ORM obiektów:

JPA Mappings of the tables mentioned earlier with the "Entity" suffix added to their table names. 
They are omitted for brevity. 
Each one contains getters and setters like JPA Pojos do. 
If someone asks for the Persistence objects code I will post it. 

jedyny punkt, w którym moi obiektów domeny wiedzieć o Model trwałości znajduje się w moim obiekcie fabrycznym CodificationChartFactory, który ma interfejsy repozytoriów, których używam do interakcji z wymienionymi wcześniej obiektami ORM. Ta fabryka jest jedyną częścią domeny, która używa repozytoriów trwałości, a więc jedyną częścią, która współdziała z warstwą trwałości.

Czy tworzenie osobnego modelu domeny jest tutaj marnotrawnym wysiłkiem? Widzę, jak mogę umieścić moje zachowania w Kodzie Codification na obiekcie Persistence. Po prostu źle się dzieje, gdy zachowujemy te zachowania na obiekcie trwałości, którego jedynym zadaniem jest pobranie rekordu z bazy danych.

Zdecydowanie mogę sprostować.

Answer 1

Oba podejścia są poprawne i są kwestią gustu z punktu widzenia projektu. Niektórzy ludzie nie chcą, aby ich obiekt domeny miał absolutnie nic wspólnego z utrwalaniem i tworzyć dodatkową warstwę obiektów Entity ... niektórzy ludzie nie uważają tego za poważny problem i chętnie korzystają z domeny obiekty jako obiekty trwałości.

Osobiście (i subiektywnie), myślę, że używanie JPA i dodatkowa warstwa obiektów Entity to niewłaściwe podejście. Celem ORM takich jak Hibernate ma być pomost pomiędzy Modelami Obiektowymi i Relacyjnymi (wiem, że to w nazwie :). Myślę, że lepszym podejściem, w przypadku, gdy chce się zachować oddzielenie, jest użycie czegoś takiego jak mybatis lub zwykły SQL, ale z pewnością nie jest to JPA ... w przeciwnym razie jest to po prostu komplikujące ze względu na złożoność (JPA nie jest najłatwiejszy do nauczenia się)

Cieszę się, że mogę mieszać i dodawać adnotacje do moich obiektów domenowych. Jak wiem, upór jest łatwiejszy w zarządzaniu ... ale jednocześnie czuję się bardzo dobrze z Hibernate/JPA i używam go od 10 lat :).

miałem bardzo podobne pytanie 3 lata temu, który napisałem na stronie programistów - Do ORMs enable the creation of rich domain models?