DDD Доменная сущность против Персистентной сущности - PullRequest
1 голос
/ 02 февраля 2020

В DDD мы говорим, что объект Entity не является представлением модели / объекта базы данных. Мы также говорим, что для правильного извлечения модели домена из приложения модель домена не должна иметь никакой информации о том, как она сохраняется или как она возвращается клиенту.

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

Значит ли это, что мы должны создать одну сущность для домена, а другую для сохраняющейся?

Я новичок в этом и не уверен, что правильный подход.

1 Ответ

2 голосов
/ 03 февраля 2020

Доменная модель имеет тенденцию быть довольно инкапсулированным делом. Так как такие доменные объекты не являются хорошими кандидатами, когда речь идет о сущностях ORM.

Если ваши доменные сущности выглядят как контейнеры данных, так что они могут служить в качестве сущностей ORM, если они украшены некоторыми атрибутами, тогда ваш домен в лучшем случае не инкапсулируется, а в худшем случае это модель c.

По моему мнению, вы, как правило, в конечном итоге получаете модель предметной области и некоторую форму ориентированной на данные модели ORM.

В некотором роде:

Как только вы начнете спрашивать, что принесет ваш ORM к столу, вы можете захотеть посмотреть, сколько вы потеряете, отказавшись от ORM. и использование какой-либо другой технологии доступа к данным с использованием исходного / низшего уровня. Может даже быть некоторое повышение производительности, которое будет сделано. Если я когда-либо получу право голоса по этому вопросу, я не использую ORM.

...