Małe agregaty

Ostatnio kilka razy spotkałem się z opinią, że w typowej aplikacji biznesowej większość agregatów będzie składać się z korzenia i value objectów. Np. tu: https://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf można przeczytać, że:

On one project for the financial derivatives sector using[Qi4j], Niclas [Hedhman] reported that his team was able to design approximately 70% of all aggregates with just a root entity containing some value-typed properties. The re-maining 30% had just two to three total entities. This doesn't indicate that all domain models will have a 70/30 split. It does indicate that a high percentage of aggregates can be limited to a single entity, the root.`

Jest to dla mnie pewien szok, bo myślałem, że w skład agregatu wchodzi zazwyczaj kilka encji. Czy podobnie wygląda to również u Was?

Na podstawie jednego projektu nie wyciągałbym wniosków. To zależy od domeny i w jakim stopniu musisz być spójny. Zakładając, że w jednej transakcji modyfikujesz tylko jeden agregat, podejście o którym piszesz (dużo agregatów, które maja tylko korzeń) premiuje wydajność kosztem spójności niezmienników. Natomiast schodząc na ziemię w 70% przypadków wychodzi, że niezmienniki da się ograć w ramach jednej encji, wtedy nie ma problemu nawet ze spójnością. To są jakieś mniej skomplikowane reguły biznesowe i to by nawet pasowało - rzadko kiedy cały system jest skomplikowany.

Ja spotkałem się w 90% aplikacji z podejściem, że modyfikujemy wiele encji naraz i nie było tam DDD :D pozostałe 10% zawierały 1-encyjne agregaty (mikroserwisy).

Ogólnie agregaty idealnie powinny być małe. Nie jest to konieczna reguła ale dobra praktyka. Czasem również jedna "logiczna encja" może być zamodelowana za pomocą wielu agregatów(!). Dzieje się tak wtedy kiedy agregat jest bardziej granicą transakcji jakiegoś procesu niż 1:1 mapowaniem między jakimś rzeczywistym bytem a odzwierciedleniem tego w kodzie.