Разница между сущностью и совокупностью в проекте, управляемом доменом

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

2 ответа

Из перспективы проектирования с учетом домена DbContext является реализация UnitOfWork, а DbSet - реализация репозитория.

Это то место, где контрастность DDD и EntityFramework. DDD предлагает иметь репозиторий для каждого заполнителя, но EntityFramework создает по одному на Entity.

Итак, что такое совокупный корень?

Предположим, что у нас есть социальная сеть и сущности, такие как Post, Like, Comment, Tag. (Я считаю, что вы можете себе представить отношения между этими сущностями). Некоторые из объектов - "Агрегатный корень"

Чтобы найти общий корень (ы), я пытаюсь найти, какие сущности не могут жить без другого. Например, Like или Comment не могут жить без Почты. Затем Post является совокупным корнем, и нам нужен PostRepository или превратить объект Post в репозиторий (известная коллекция, например, предмет интерфейса). Операции CRUD для Comment и Like (а также Post) должны оставаться в этом репозитории.


Определение довольно прямолинейно:

  • Агрегат: в основном кластер объектов, который создает четкую ссылку на корневой агрегат, поэтому, когда вы ссылаетесь на корень, вы можете обеспечить целостность агрегатов в целом.

Агрегат - это шаблон в проекте, управляемом доменами. Агрегат DDD - это кластер объектов домена, который можно рассматривать как единое целое. примером может быть заказ и его позиции, они будут раздельными объектов, но полезно обрабатывать порядок (вместе со своей строкой элементы) как единый агрегат.

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

Агрегаты - это основной элемент переноса хранилища данных - вы запрос на загрузку или сохранение целых агрегатов. Сделки не должны кросс-агрегатные границы.

Агрегаты DDD иногда смешиваются с классами сбора (списками, карты и т.д.). Агрегаты DDD - это концепции домена (заказ, посещение клиники, плейлист), а коллекции - общие. Агрегат часто будет содержат множественные коллекции вместе с простыми полями. Срок "совокупность" является общей и используется в различных контекстах (например, UML), и в этом случае он не ссылается на ту же концепцию, что и DDD-агрегат.

  • Entity: в контексте модели данных описывается структура данных независимо от сохраненной формы.

В EDM рассматриваются проблемы, возникающие из-за того, что данные хранятся в многие формы. Например, рассмотрите бизнес, который хранит данные в реляционные базы данных, текстовые файлы, XML файлы, электронные таблицы и отчеты. Это создает серьезные проблемы при моделировании данных, дизайн приложений и доступ к данным. При разработке ориентированных на данные приложений, задача состоит в том, чтобы написать эффективный и поддерживаемый код без ущерба для эффективного доступа к данным, хранения и масштабируемости. Когда данные имеют реляционную структуру, доступ к данным, их хранение и Масштабируемость очень эффективна, но эффективна и удобна в написании код становится сложнее. Когда данные имеют структуру объекта, компромиссы отменены: написание эффективного и поддерживаемого кода за счет эффективного доступа к данным, хранения и масштабируемости. Даже если можно найти правильный баланс между этими компромиссами, новый проблемы возникают, когда данные перемещаются из одной формы в другую. Модель данных сущности решает эти проблемы, описывая структура данных в терминах сущностей и отношений, которые независимо от любой схемы хранения. Это делает сохраненную форму данных не имеет отношения к разработке и разработке приложений. И потому что сущности и отношения описывают структуру данных, поскольку они используемые в приложении (а не в его сохраненной форме), они могут развиваться как приложение развивается.

Определение может различаться, это определяются Мартином Фаулером и Microsoft. Надеюсь, это еще раз поясняет разницу.

licensed under cc by-sa 3.0 with attribution.