Основываясь на вашей терминологии, я предполагаю, что вы выполняете DDD на основе книги Эрика Эванса. Похоже, вы уже определили проблему с вашим первоначальным подходом к моделированию, и вы правы.
Вы упомянули, что думали о поставщике как о Value Object... Я полагаю, что это не так. Value Object — это то, что в первую очередь идентифицируется по своим свойствам. Например, дата «30 сентября 2009 г.» является объектом-значением. Почему? Потому что все экземпляры даты с другой комбинацией месяца/дня/года являются разными датами. Все экземпляры даты с одним и тем же сочетанием месяца/дня/года считаются идентичными. Мы никогда не будем спорить об обмене моего "30 сентября 2009" на ваше, потому что они одинаковые :-)
С другой стороны, Entity в первую очередь идентифицируется своим «ID». Например, банковские счета имеют идентификаторы — все они имеют номера счетов. Если в банке есть два счета, на каждом по 500 долларов, и номера их счетов разные, то и они тоже. Их свойства (в данном примере их баланс) не идентифицируют их и не подразумевают равенства. Бьюсь об заклад, мы бы поспорили об обмене банковскими счетами, даже если бы их балансы были одинаковыми :-)
Итак, в вашем примере я бы рассматривал поставщика как Entity, поскольку я полагаю, что каждый поставщик в первую очередь идентифицируется по его идентификатору, а не по его свойствам. Моя собственная компания имеет то же имя, что и две другие в мире, но мы не все взаимозаменяемы.
Я думаю, что ваше предложение о том, что если вам нужны представления для CRUD-обработки объекта, то это Entity, вероятно, верно как практическое правило, но вам следует больше сосредоточиться на том, что отличает один объект от других: свойства или идентификатор.
Теперь, что касается Aggregate Root, вы хотите сосредоточиться на жизненном цикле и управлении доступом к объектам. Учтите, что у меня есть блог со многими сообщениями, каждое из которых имеет много комментариев - где Aggregate Root (ы)? Начнем с комментариев. Есть ли смысл комментировать без поста? Вы бы создали комментарий, а затем нашли сообщение и прикрепили его к нему? Если вы удалите пост, оставите ли вы комментарии к нему? Предлагаю пост Aggregate Root с одним "листом" - комментариями. Теперь рассмотрим сам блог — его отношения с постами аналогичны отношениям между постами и комментариями. Это тоже по-моему Aggregate Root с одним "листом" - постами.
Итак, в вашем примере существует тесная связь между компанией и поставщиком, при которой, если вы удалите компанию (я знаю... у вас, вероятно, есть только один экземпляр компании), вы также удалите ее поставщиков? Если вы удалите «Старбакс» (кофейная компания в США), перестанут ли существовать все ее поставщики кофейных зерен? Все это зависит от вашего домена и приложения, но я предполагаю, что более чем вероятно, что ни один из ваших Entities не является Aggregate Roots, или, возможно, лучший способ думать о них состоит в том, что они являются совокупными корнями, каждый из которых не имеет «листьев» (нечего агрегировать). Другими словами, компания не контролирует доступ к поставщикам и не контролирует их жизненный цикл. Он просто имеет отношения «один ко многим» с поставщиками (или, возможно, «многие ко многим»).
Это подводит нас к Repositories. Repository предназначен для хранения и извлечения Aggregate Roots. У вас есть два (технически они ничего не агрегируют, но это проще, чем сказать «репозитории хранят совокупные корни или сущности, которые не являются листьями в совокупности»), поэтому вам нужно два Repositories. Один для компании и один для поставщиков.
Надеюсь, это поможет. Возможно, здесь скрывается Эрик Эванс и расскажет мне, где я отклонился от его парадигмы.
person
SingleShot
schedule
01.10.2009
