Я занимаюсь некоторыми деталями реализации, рассматривая термины, упомянутые в названии выше.Aggreate Root, Aggregates, Entities, Value Objects
Может ли кто-нибудь сказать мне, верно ли мое толкование?
Для справки я смотрю на Домен CRM
Как AggregateRoot я мог видеть клиентов.
Это может иметь Entities как Адрес, который содержит улицу, почтовый индекс и так далее.
Теперь есть что-то вроде Контакты и деятельности это должно быть, по крайней мере агрегаты. Правильно? Теперь, если контакты и действия будут иметь сложную бизнес-логику. Например, «Каждый раз, когда создается контакт типа заказа, рабочий процесс заказа должен быть запущен»
Должен ли тогда контакт быть скоплением совокупности? Каковы могут быть последствия внедрения, которые могут возникнуть в результате этого?
Более подробно при поиске и событии Sourcing, будет ли у каждого агрегата собственный Stream? В этом случае у Клиента могут быть тысячи действий.
Было бы здорово, если бы кто-нибудь мог руководить ими, в какой части мое понимание правильное и которое я отличаю от общей интерпретации.
Не существует общей интерпретации того, как моделировать тип домена, поскольку каждый домен уникален. Домен CRM может быть смоделирован по вашему описанию или иным образом. Я предлагаю вам определить aggregate/entity/VO, как вы их понимаете, и задавать конкретные проблемы, а не просто размытый пример. – guillaume31
Только одно: обычно «Адрес» является классическим примером объекта значения. Вы уверены, что вам это нужно? –
Ваше право, адрес должен быть скорее объектом value.as, он не должен быть идентифицирован и всегда будет существовать только внутри данного агрегата –