DDD Когда я должен создать объект домена и объект persistence вместо использования объекта persistence в качестве объекта домена?

Question

Поскольку я работаю с моим пониманием проекта, управляемого доменом, я нахожу, что у меня есть правило, которое, похоже, работает, хотя я бы хотел, чтобы он был чрезмерным, и также хотел бы видеть другие перспективы в той же ситуации.

Мой вопрос заключается в следующем: «Когда модель домена и модель сохранения сохраняются в отдельных объектах?» Мой язык выбора - это Java на данный момент, и я использую модель репозитория Spring Data.

Я вижу три основных ответа на мой вопрос.

1. Всегда используйте отдельные объекты домена из объектов сохранения.
2. Использование отдельных объектов домена только при использовании методов домена (поведения) на объектах сохранения не является практичным.
3. Использовать объекты сохранения как объекты домена во всех случаях.

Чтобы задать вопросы о DDD, я обнаружил, что должен использовать пример ограниченного контекста, поскольку я еще недостаточно знаю об DDD, чтобы спросить более абстрактным образом.

Вот мой иллюстративный контекст ограничен: скажем, у меня есть система кодификации со следующими бизнес-правилами:

1. Каждый закон о книгах должны быть классифицированы.
2. Каждый закон имеет идентификатор с двумя частями, префикс номера кодификации и суффикс коаксигации кодирования. (Пример: 100-0100, 599-2030).
3. Существует множество правовых юрисдикций, которые используют систему кодирования законов, и они должны иметь возможность создавать свои собственные соратники, но префиксы кодификации являются глобальными и должны быть одинаковыми во всех юрисдикциях для облегчения общей сопоставимости.
4. префиксы номера кодировки сгруппированы в широкие категории кодирования. Кодификация категория имеет диапазон номеров, например, 100-199, 200-299, 700-799 и т.д.

Чтобы выразить это ограниченный контекст как модель инерционности я следующее:

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 

Я знаю, сначала я должен начать с модели домена. У меня есть модель настойчивость и модель предметной области

В моей модели домена У меня есть домен три объектов

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 объектов:

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. 

Единственная точка, в которой мои объекты области знают о модель настойчивости находится в моем заводском объекте CodificationChartFactory, который имеет интерфейсы репозитория, которые я использую для взаимодействия с объектами ORM, упомянутыми ранее. Эта фабрика является единственной частью домена, которая использует репозитории сохранения, таким образом, единственную часть, которая взаимодействует с уровнем сохранения.

Создает отдельную модель домена здесь расточительное усилие? Я могу видеть, как можно поместить мое поведение CodificationChart в объект Persistence. Это как-то не так, чтобы помещать эти поведения в объект персистентности, единственной задачей которого является получение записи из базы данных.

Я определенно поддаюсь исправлению.

Answer 1

Оба подхода являются правильными и являются предметом вкуса с точки зрения дизайна. Некоторые люди не хотят, чтобы их объект домена имел абсолютно какое-либо отношение к сохранению и создавал дополнительный слой объектов Entity ... некоторые люди не думают, что это серьезная проблема, и с удовольствием продолжаем использовать домен объекты как объекты сохранения.

Лично (и субъективно), я считаю, что использование JPA и дополнительный слой объектов Entity - неправильный подход. Цель ORM, таких как Hibernate, - быть мостом между объектными и реляционными моделями (я знаю, что это имя :). Я думаю, что подход лучше подходит, если вы хотите, чтобы все было разделено, - использовать что-то вроде mybatis или простого SQL, но определенно не JPA ... иначе это просто добавляет сложности ради сложности (JPA не самая простая основа для изучения)

Я рад жить с микс и аннотировать объекты моего домена. Как я знаю, это упрощает управление настойчивостью ... но в то же время я чувствую себя очень комфортно с Hibernate/JPA и использую его в течение 10 лет :).

У меня был очень похожий вопрос 3 года назад, который я отправил на программистов сайте - Do ORMs enable the creation of rich domain models?