Насколько я понимаю, у вас должно быть два отдельных Агрегата, Document и Binder, и использование Saga (Диспетчер процессов), чтобы в конечном итоге привести всю систему в правильное состояние.Другими словами, вы должны смоделировать изменение связанного документа как бизнес-процесс.
Эта Saga будет запускаться со всей информацией, касающейся изменения документа (т. Е. Со всеми измененными свойствами в документе), затем она отправит в Binder команду, которая проверит свой собственный инвариант, и если все будетХорошо, тогда он отправит команду обновления в агрегат документов.Он также должен реагировать на все события, которые могут привести систему в недопустимое состояние, то есть события, сгенерированные агрегатом Binder, поскольку существует вероятность того, что документы в подшивке перейдут в недопустимое состояние из-за мутации агрегата Binder.
Другой архитектурой будет отправка команды обновления непосредственно в агрегат документов без проверки инварианта.Затем Saga реагирует на события обновления документа, отправляя команду в агрегат Binder.Если скоросшиватель говорит, что он не в порядке, тогда Saga отправит компенсирующие команды в связанный документ.Этот дизайн был бы более приемлемым для недействительных документов, но он проще.
Оба проекта в конечном итоге приведут систему в действительное состояние, но первый будет минимизировать время, в течение которого недействительный документ существует за счет повышенной сложности.потому что Saga должен был бы быть запущен и хранить информацию об изменении документа.
Альтернатива состоит в том, что вы создаете новую вложенную сущность внутри Binder Aggregate, а именно BindedDocument, но эта сущность не кажетсяконцептуально отличаться от совокупности документов.Это отражается в дублировании кода, которое у вас будет.