Доменный Управляемый Дизайн: Когда сделать Совокупный Корень?
Вы действительно хотите определить пользовательский виджет и использовать виджет внутренний класс Медиа для определения JS (и CSS?) файлы, которые должны быть включены в страницу для виджета для работы. Если Вы делаете это правильно, можно сделать виджет абсолютно автономным и допускающим повторное использование. См. django-markitup для одного пример выполнения этого (он имеет допускающий повторное использование виджет для MarkItUp! универсальный редактор разметки ).
Тогда использование formfield_callback (см. ответ James Bennett) легко применять тот виджет ко всему DateField в форме.
2 ответа
Исходя из вашей терминологии, я предполагаю, что вы выполняете DDD на основе книги Эрика Эванса. Похоже, вы уже определили проблему при первом запуске моделирования, и вы правы.
Вы упомянули, что думали о поставщике как объект-ценность ... Я полагаю, что это не так. Объект значения - это что-то, что в первую очередь определяется его свойствами. Например, дата «30 сентября 2009 г.» является объектом значения. Почему? Поскольку все экземпляры даты с разным сочетанием месяца / дня / года являются разными датами. Все экземпляры даты с одним и тем же сочетанием месяц / день / год считаются идентичными. Мы никогда не станем спорить о замене моего "30 сентября 2009 г." на ваше, потому что они одинаковы: -)
Сущность , с другой стороны, в первую очередь идентифицируется по своему " но вам следует больше сосредоточиться на том, что отличает один объект от других: свойствах или идентификаторе.
Что касается Aggregate Root s, вам нужно сосредоточиться на жизненном цикле и управлении доступом к объектам. Учтите, что у меня есть блог с множеством сообщений, каждая из которых содержит множество комментариев - где находится / находятся Aggregate Root (s)? Начнем с комментариев. Есть ли смысл оставлять комментарий без поста? Можете ли вы создать комментарий, а затем найти сообщение и прикрепить к нему? Если вы удалите сообщение, оставите ли вы его комментарии? Я предлагаю публикацию Совокупный корень с одним «листом» - комментариями. Теперь рассмотрим сам блог - его отношения с сообщениями аналогичны отношениям между сообщениями и комментариями. На мой взгляд, это тоже Aggregate Root с одним «листом» - сообщениями.
Итак, в вашем примере, существуют ли прочные отношения между компанией и поставщиком, при которых, если вы удалите компанию (я знаю ... у вас, вероятно, есть только один экземпляр компании), вы также удалите ее поставщиков? Если вы удалите "Starbucks" (кофейная компания в США), все ли ее поставщики кофейных зерен прекратят свое существование? Все это зависит от вашего домена и приложения, но я предполагаю, что более чем вероятно, что ни одна из ваших сущностей не является агрегированными корнями , или, возможно, лучше думать о них, что они являются агрегированными корнями. каждый без «листьев» (нечего агрегировать). Другими словами, компания не контролирует доступ к поставщикам и не контролирует их жизненный цикл. Он просто имеет отношения «один ко многим» с поставщиками (или, возможно, «многие ко многим»).
Это подводит нас к репозиториям . Репозиторий предназначен для хранения и извлечения агрегированных корней . У вас их два (технически они ничего не агрегируют, но это проще, чем сказать «в репозиториях хранятся агрегированные корни или объекты, которые не являются конечными в агрегате»), поэтому вам нужны два репозитория . Один для компании и один для поставщиков.
Надеюсь, это поможет. Возможно, здесь прячется Эрик Эванс и расскажет мне, в чем я отклонился от его парадигмы.
Один для компании и один для поставщиков.Надеюсь, это поможет. Возможно, здесь прячется Эрик Эванс и расскажет мне, в чем я отклонился от его парадигмы.
Один для компании и один для поставщиков.Надеюсь, это поможет. Возможно, здесь прячется Эрик Эванс и расскажет мне, в чем я отклонился от его парадигмы.
Для меня это не проблема - поставщик должен иметь собственное хранилище. Если есть какая-то логическая возможность того, что объект может существовать независимо в модели, тогда он должен быть корневым, иначе вы в любом случае просто в конечном итоге проведете рефакторинг, что является избыточной работой.
Корневые объекты всегда более гибкие, чем объекты значений, несмотря на дополнительную работу по реализации заранее. Я обнаружил, что объекты-значения в модели со временем становятся все реже по мере развития модели, и объекты, которые остаются объектами-ценностями, обычно были теми, которые вы могли бы логически ограничить таким образом с первого дня.
Если компании разделяют поставщиков, то наличие поставщика в качестве поставщика корневой объект также удаляет избыточность данных, поскольку вы не дублируете определение поставщика для каждой компании, а вместо этого делитесь ссылкой,