Powiedzmy, że zbieramy sobie wymagania do nowego systemu, modelujemy domenę i wychodzi nam, że system będzie mieć agregat Order składający się z aggregate roota Order oraz encji OrderItem (oklepany przykład dla ustalenia uwagi). Piszemy system i wszystko ładnie działa. Potem za jakiś czas klient przychodzi i mówi, że chce mieć funkcjonalność X, której zaimplementowanie będzie wymagać operacji na encjach OrderItem pochodzących z różnych agregatów Order i w sumie aggregate root Order w ogóle nie jest do niczego w tym przypadku potrzebny, a jedynie będzie przeszkadzać (przydałby się bezpośredni dostęp do OrderItem). Z drugiej strony nie mamy np. repozytorium dla OrderItem, bo zakładamy, że repozytoria operują na aggregate rootach. No i jak teraz postąpić? Zrobić z OrderItem agregat i zmieniać wszystkie istniejące serwisy wykonujące operacje na Order?
Opis bardzo ogólnikowy ale jeśli faktycznie dochodzi do sytuacji w których tak jak piszesz nagle okazuje się że dotychczasowy agregat Order (jako całość, a więc root jak i encje) nie będzie angażowany to masz dwie opcje zależnie od tego jak to będzie wyglądać od tej pory. Jeśli faktycznie nie będzie już potrzeby używać Order to wydaje się rozsądne zrobić to co sugerujesz i to wszystko wymienić. W przeciwnym razie masz dwa różne procesy które w zasadzie powinny działać niezależnie- a więc zachowujesz dotychczasowy agregat jak i tworzysz nowy ja potrzeby nowych (dodatkowych) wymagań.
@Aventus: Czyli w drugim przypadku mielibyśmy agregat Order zawierający encje OrderItem używany przez istniejące procesy i drugi agregat XOrderItem używany przez nowy proces? Zarówno OrderItem w agregacie Order, jak i XOrderItem pochodziłyby z tego samego źródła danych.
Hmm, teoretycznie ma to sens. Zdarzały Ci się podobne sytuacje?
Tak, mieliśmy system gdzie większość danych pochodziło bezpośrednio od interakcji z użytkownikiem oraz dodatkowo część danych pochodziło z zewnętrznych zaufanych systemów. Każdy z tych dwóch procesów wymagał walidowania innych zasad biznesowych, miał trochę inne pod-procesy itp.
Poza tym zawsze możesz spróbować podpiąć pod to jakiś wcześniejszy proces- coś co na początku "obrobi" odpowiednio dane wejściowe (jakiś inny agregat) ale końcowo dane zakończą w "głównym" agregacie Order, czyli w ramach procesu przekonwertujesz to w model kanoniczny.
Ogólnie to w większych systemach DDD poleca się opierać system o zdarzenia (event-driven) ponieważ to znacznie ułatwia później dodawanie nowych procesów itp. Szczególnie jeśli stosuje się event modelling. Pozwala to osiągnąć open/closed principle na poziomie architektury.