У меня есть два элементарных корня и два неагрегатных корневых объекта:
Я знаю, что отношение D -> B нарушает принцип DDD.
Я слышал, что в большинстве случаев решение заключается в том, чтобы сделать связанный объект новым агрегированным корнем.
Но делает B для нового совокупного корня действительно опцией, если B - реальный ребенок A (B не может жить без A)?
Я согласен с тобой, иногда просто не имеет смысла отделять одну сущность от ее совокупности, потому что она в ней так естественна. Это одна из причин, по которой я не полностью продаюсь по методу "малых агрегатов", который рекомендует .
В таком случае то, что вы можете сделать, это получить ссылку на B путем обхода экземпляра A вместо его получения. В конце концов, если B не может существовать без A, нет никаких причин, чтобы объекты вне совокупности знали о конкретном B и не знали о его A.
Прежде всего, это не мышление DDD, это мышление РСУБД. В DDD вы моделируете бизнес-процессы так, как они есть в реальном мире, у вас нет понятий "один-ко-многим" и т.д. Поэтому забудьте о DB, внешних ключах и так далее.
Каковы ваши ограниченные контексты (BC)? Каждый агрегат сам по себе является BC, поэтому они могут иметь различное представление понятий EVEN, если они называются одинаковыми.
Если я понимаю убедительно, кажется, что A B C D являются частью одного агрегата. Это не означает, что они определены ТОЛЬКО в этом агрегате и ТОЛЬКО в этой форме. Однако, если C является полноправным AR в каком-либо другом BC, вполне возможно, что в ЭТОМ контексте будет отображаться только как идентификатор или несколько свойств (интерфейсы ОЧЕНЬ удобны для этого материала). Поэтому, даже если оба они именованы C, они отличаются друг от друга, имея только поведение, требуемое конкретным контекстом.
DDD работает с большим количеством BC, и модели действительны только для одного BC. это означает, что в вашем приложении у вас будет несколько определений A, B, C в соответствии с каждым BC, и каждое определение может немного отличаться. Это означает, что на всех случаях не существует только одной модели (и я не говорю о CQRS здесь, просто DDD).
Я не знаю много о домене, чтобы на самом деле придумать что-то более конкретное. Но просто постарайтесь представить вещи такими, какие они есть, и как они работают на самом деле.