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

внутри одного контекста - да, вполне можно. Ну то есть там риски существенно ниже

фух.. Блонди преобретает каштановый цвет ))

главное между контекстами не шалить

вооот, тут я согласна ))

@kion78

Выше @fes0r  приводил пример задач которые могут решаться "Мы хотим разделять и изолировать разные части логики для:

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

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

вот все это понятные боли)) а у вас какая проблема?

а я выше написал )

зацепился за "более 2 статусов"

но у нас нет этой боли, которую вы описали про отделы логистики и продажников, даже не знаю к сожалению или к счастью

у нас статус тупо информационный, ну и минимальная логика, что нельзя оплатить "оплаченный" заказ и т.п.

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

Есть такое что при  статусах, у агрегата часть полей становятся не уместны?
Ну например есть юзер, со статусом "ожидает подверждение инвайта" - у него такие поля как логин, электропочта, пароль - в принципе  еще не существуют. Вот по аналогии с таким примером в вашей предметной области - бывают ситуации когда в зависимости от статуса сущностей часть полей как бы преждевременны, ну или наоборот уже не уместны ?

корзина отдельная сущность со своими отдельными связями на мелкие агрегаты типа лояльности

заказ создается в момент когда клиент желает создать заказ

всегда можно начать закапываться в вопросах "а что если стоимость товара поменялась в момент оформления заказа" 🙂. в отдельных страназ за это могут и засудить а где-то это и вовсе мошейничество

как сказал бы @GDXbsv - ответим "Упс... Извините, продать не можем" ))

Был как-то ИМ там я делал фиксирование истории изменения цены и в зависимости когда в корзину положили, такую цену и выдавать)

ну вот тут - может быть заказ с несколькими статусами, а может быть сущность "заявка на заказ" (название условно) и у этой сущности может быть метод "оплатить" и отдельная сущность "оплаченный заказ" (название условно) - и у этой сущности уже свой набор методов ( в частности отсутствует метод оплатить).
Т.е. уже сам факт проверок отпадает

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

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

это корзина, а оплата может пройти и через время

Ну так в корзине товар лежал неделю. Допустим я сегодня положил за 500р, через два дня стал стоить 700. В пределах недели счёт выставлялся на 500.