Как вы обрабатываете совокупный корень с набором дочерних объектов, частота обновления которых отличается от корня?

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

Каскадное удаление (в отношении совокупных границ) скорее желательно, чем правило. Вы всегда можете обеспечить тот факт, что Parent все еще живет, потребовав его в том месте, где вы загружаете Child объекты. Благодаря этому дизайну вы можете создавать Parent и Child разные агрегаты, сохраняя при этом правило, согласно которому никакие "свободно плавающие" Child агрегаты не могут быть запрошены. А удалить агрегаты Child в ответ на удаленный Parent легко, если у вас есть доменные события.

Примечание. Все это исходит из предположения, что инварианты вашего домена позволяют в первую очередь разделять агрегаты.

Это может быть лучше в формате обсуждения, а не в формате вопросов и ответов. Я бы рекомендовал попробовать аудиторию на DomainDrivenDesign или DDDCQRS

Вы уверены, что у вас есть бизнес-требование по удалению данных в вашей модели домена? Это действительно необычно — в большинстве моделей доменов, которые я видел, агрегат достигает состояния «конца жизни» (пример: AccountClosed), но фактически не удаляется из системы.

Распространенная ловушка в агрегированном дизайне — думать о структуре сущностей. «А имеет Б» не обязательно означает, что они являются частью одного и того же агрегата; ключевая идея заключается в том, что «A должен поддерживать согласованность B и C». Вы можете думать об этом как о графике; состояние B и состояние C — узлы в графе, правила согласованности — ребра. Если вы не можете пройти по графу от B до C, то они не должны быть частью одного и того же агрегата и, вероятно, не должны быть.

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

В этом на меня повлияло эссе Уди Дахана Гоночные условия не Существует; связывая этот набор конфигураций с остальной частью агрегата, вы, по сути, утверждаете, что изменения в конфигурации (которые случаются редко) понимаются бизнесом как происходящие точно между двумя другими изменениями агрегата. 3M транзакций в день в среднем 1 за 30 мс; Вы действительно точно планируете изменения конфигурации?

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

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

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