Имеет ли смысл когда-либо иметь фабрику Value Object, когда следует правилам DDD?
Недавно я думал о некоторых проблемах, которые возникали у меня в прошлом, когда пытался спроектировать конкретную модель предметной области, скажем, адрес, который можно редактировать в заданном контексте, но нельзя редактировать в другом. Мой нынешний способ мышления состоит в том, что у меня будет и версия объекта значения адреса, и объект для адреса, возможно, связанный с чем-то вроде учетной записи клиента, чтобы получить его идентичность.
Теперь я понимаю, что если я когда-либо создаю новый адрес, например, когда он вводится пользователем, мне, скорее всего, также понадобится продолжить редактирование этого адреса и, возможно, редактирование любых ранее существовавших адресов. в этом же ограниченном контексте. По этой причине я могу предположить, что в этом контексте адрес должен быть смоделирован как объект, а не как объект значения. Это подводит меня к моему основному вопросу, который заключается в том, что если вы всегда должны использовать сущности при изменении существующего набора данных или создании новых данных, то имеет ли смысл когда-либо иметь Фабрику для создания какого-либо объекта-значения?
Правило, которое начинает проявляться для меня, когда я следую этой линии мышления, заключается в том, что объекты-ценности должны создаваться только для представления вещей, которые являются статическими для приложения или вещей, которые уже были сохранены в базе данных, но не вещи, которые являются временными в текущем контексте домена. Таким образом, единственное место, в котором я должен создавать объекты значений, - это когда они повторно гидратируются / материализуются в или от имени совокупных корневых репозиториев для постоянных значений или внутри службы в случае статических значений. Это начинает казаться мне довольно ясным, однако меня беспокоит, что я нигде не читал, где кто-то делает такие же выводы. В любом случае, я надеюсь, что кто-то может подтвердить мои выводы или исправить меня.
1 ответ
которые можно редактировать в данном контексте, но нельзя редактировать в другом
Различия в настройках изменчивости для объекта в разных контекстах также могут быть представлены на уровне приложения. Это операционная проблема, возможно, связанная с аутентификацией и авторизацией, и сервис приложений является удобным местом для этой логики. Различие между ВО и организацией не решает эти проблемы напрямую. Тот факт, что VO должен быть неизменным, не означает, что объект не может изменить значение VO, на которое он ссылается. Например, пользователь может ссылаться на неизменяемое значение адреса, однако операция редактирования может обновить пользователя для ссылки на новое значение. Разрешение пользователю редактировать адрес в одном контексте, а не в другом, может быть представлено в виде значений разрешений, связанных с соответствующим контекстом.
Это подводит меня к моему основному вопросу, который заключается в том, что если вы всегда должны использовать сущности при изменении существующего набора данных или создании новых данных, то имеет ли смысл когда-либо иметь Фабрику для создания какого-либо объекта-значения?
Конечно, имеет смысл иметь фабрику для создания экземпляров VO. Это может быть статический метод в классе VO или выделенный объект, в зависимости от ваших предпочтений. Однако ВО не должен использоваться для удовлетворения требований изменчивости модели предметной области. Вместо этого, как указано выше, это должно быть обработано на уровне приложения.