Domain Driven Design - обновление ценностных объектов

Очень распространенный подход к работе с нижестоящими системами - использование какого-либо механизма обмена сообщениями. управляемая событиями архитектура отлично справляется с этой задачей.

Иногда вам приходится спрашивать себя, действительно ли нужно вообще обновлять данные. Возможно, для активного заказа вам может потребоваться обновить имя клиента, когда восходящий BC публикует соответствующее событие, содержащее новое имя. Выполненные заказы вполне можно оставить в покое. Обычно это происходит при изменении чьей-либо фамилии.

Другой пример, когда вы можете не захотеть изменять данные, - это описание продукта. Если клиент заказал коробку красных ручек с артикулом BP-001, а серверная часть обновляет ошибку и меняет описание на коробку синих ручек, это может привести к интересному аргументу.

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

Иногда вы разыгрываете колоду, а иногда разыгрываете ту руку, которую вам уже раздали.

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

Должен ли я по-прежнему моделировать его как объект значения, содержащий идентичность, и всегда запрашивать необходимые данные, или я могу создать объект значения, чтобы он все время содержал необходимые данные?

По-разному.

(Если вы изучаете DDD, привыкните к этому ответу - он часто встречается.)

Одна из ключевых идей агрегатов состоит в том, что вы разделяете свою информацию; любая заданная часть информации в вашей модели предметной области принадлежит не более чем одному агрегату, то есть только одному агрегату разрешено устанавливать блокировку на эти данные и изменять их.

Все, кто работает с этими данными, смотрят на разблокированную копию. О разблокированных копиях важно помнить, что они могут быть устаревшими (агрегат Учетной записи может изменять информацию, не запрашивая разрешения у агрегата Заказа).

Итак, что вы действительно спрашиваете, это что-то вроде того, должен ли агрегат заказов всегда запрашивать новую копию информации об учетной записи, когда она ему нужна? Или мы должны вместо этого кэшировать копию этой информации внутри агрегата заказов?

Ответ будет зависеть от ряда вещей, например, всегда ли доступна информация об учетной записи? насколько терпима ваша бизнес-логика Заказа к устаревшей информации об Учетной записи? и так далее.

(Подсказка: если ваша бизнес-логика Заказа вообще не допускает устаревшей информации об Учетной записи, это убедительно свидетельствует о том, что вы неправильно разработали свои совокупные границы)