Дизайн, управляемый доменом — модель домена и объект Hibernate

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

Модели может быть реализован по-разному. В вашем примере вы показали две разные реализации, которые представляют один и тот же Модель.

Этот статья говорит о проблеме, с которой вы столкнулись.

Вы спросили, совпадает ли Модель домена с Спящий объект. Ответ НЕТ.

Спящий объект — это специфика технологии, в данном случае это объект, являющийся частью структуры ORM. Спящий объект и Объект DDD, как определено DDD, являются разными вещами, поскольку Объект DDD является абстрактной вещью, если определяет идею (шаблон) и дает рекомендации о том, что это за идея и что она представляет. Спящий объект — это объект Java, который создается, отслеживается, сохраняется, отбрасывается и собранный мусор.

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

Вы используете Спящие объекты или любой другой тип технологии, такой как Сущность Framework (это то же самое, объект в программе OO) реализовать Модель домена. Один и тот же Модель домена может быть реализован на разных языках с использованием разных технологий. Эти реализации будут различаться в зависимости от того, что предоставляет технология.

Например, если вы пишете серверную часть NodeJs с MongoDB и хотите использовать ORM для реализации Модель домена, вы застрянете с использованием Шаблон активной записи (вероятно, Mongoose), потому что это единственные, которые люди реализовали (по крайней мере, я мог не нашел никаких других фреймворков, которые не являются Active Record, если вы их найдете, пожалуйста, дайте мне знать). Реализация DDD таким образом может быть очень сложной (и может быть действительно отстойной).

В книга DDD Эрик Эванс рассказывает о том, как технологии могут помочь вам реализовать Модель или могут бороться с вами на всем пути. Когда он борется с вами или не предоставляет хороших механизмов, вы просто знаете, как это обойти.

Иногда у ORM есть требования, и вы не хотите выставлять эти вещи в свой другой код, поэтому вы можете использовать Wrapper, как в вашем Способ 2. Некоторые из них включают в себя такие вещи, как общедоступный метод get set, общедоступные конструкторы и т. д. Большинство из них используют отражение и могут иметь приватные вещи, но все же есть много проблем, таких как наличие приватного конструктора без параметров для удовлетворения фреймворка, и ваш код становится грязным с большим количеством вещи, которые не связаны с вашей моделью, но существуют, потому что они нужны вашей структуре (ВАУ!). Это тоже может привести к ошибкам. Легче совершить ошибку, имея конструктор по умолчанию, вместо хороших конструкторов с параметрами или статическими фабричными методами. Эта оболочка может представлять более чистую модель предметной области без наличия Необходимое зло, который несут фреймворки, чтобы вы могли их использовать.

В одном проекте это стало настолько уродливым, что мы решили использовать чистый SQL в Репозитории, чтобы нам не приходилось иметь дело со всеми вещами фреймворка. Реализация была красивой, чистой, и мы сделали это быстрее. Некоторые люди думают, что фреймворк ускоряет работу, и в большинстве случаев это правда, но когда фреймворк борется с вами, а код содержит ошибки, отладка не доставляет удовольствия, поэтому написание сырого SQL может быть легкой задачей. В этом случае следуя рекомендациям DDD с использованием агрегатов, наша модель была хорошо отделена, и у нас не было сложных запросов, которые могли бы замедлить разработку.

Are Hibernate Entity is same as the domain models?

Не на самом деле нет. На практике грань между ними может быть очень размытой.

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

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

Другими словами, репозиторий выполняет (в некотором смысле) две функции; один знает, как получить данные из «агрегата» и сохранить, другой знает, как считывать данные из хранилища и строить из них агрегат.

ORM — это один из способов получить данные из внешней реляционной базы данных в локальную память.

Таким образом, ваша история загрузки может выглядеть так:

Use an identifier to load data from the database into a hibernate entity
copy the data from the hibernate entity into an aggregate
return the aggregate

И магазин может выглядеть

Copy data from the aggregate into a hibernate entity
Save the hibernate entity.

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

Вместо этого вы часто будете видеть, что логика домена в конечном итоге записывается в объекты ORM, и вы добавляете кучу комментариев, чтобы было ясно, какие биты присутствуют, потому что они требуются для гибернации.

Если вы посмотрите на пример ДДД Грузовые перевозки, вы увидите, что они использовали второй подход, когда агрегат имеет скрытый немного поддержки спящего режима внизу.

Domain and Entity are different functions. Domain model "has-an" entity

Ваши коллеги правы: они равнозначны по большинству важных аспектов. Модель домена зависит от ваших объектов гибернации.

Ни один из них не соответствует тому, что описал Эванс в своей книге.

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

Если бы вы действительно разделяли их, то ваш репозиторий выглядел бы примерно так:

Agent AgentRepository::find(id) {
    AgentEntity e = entityManager.find(id)
    Agent a = domainFactory.create( /* args extracted from e */ )
    return a
}

void AgentRepository::store(Agent a)
    AgentEntity e = entityManager.find(id)
    copy(a, e)
}

// I think this is equivalent
void AgentRepository::store(Agent a)
    AgentEntity e = entityManager.find(id)
    entityManager.detach(e)
    copy(a, e)
    entityManager.merge(e)
}

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

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