агрегат не обязательно должен быть больше чем 1 энтити?

агрегат это граница транзакции, у тебя что угодно может быть границей, хоть сущность с id без единого другого поля)

типо такого видимо

никогда в жизни не слышал столько раз повторения слова "инвариант"

добавляю в свой словарный запас, буду солиднее

видимо тебе надо прошарить в UML) а я спать)

uml прошарен, не помню там "инвариантов")

спасиб что помог поразбираться

ну, тогда ты бы сразу понял что CustomerId не агрегат))) вообще схема не топ

не, я про то что vo тоже считается частью агрегата, я был не в курсе

Агрегат это не просто "кучка объектов". Это граница транзакции

https://www.dddcommunity.org/library/vernon_2011/ - вот тут есть немного сжатой инфы на эту тему

если говорить о UML, то агрегат очень близок к агрегату в UML, c тем лишь различием, что UML накладывает ограничения только на время жизни в программе во время выполнения, в ddd же это расширено, потому что мы говорим о том что инварианты агрегата не должны нарушаться, тем самым ограничивая доступ к данным на запись(или в случае отчетов, как в примере в статье, у нас транзакционное чтение) в рамках одного агрегата в рамках всего жизненного цикла данных, а не только для конкретного инстанса

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

Агрегаты призваны гарантировать консистентности стэйта (присловутые инварианты) а потому если мы только читаем и стэйт не меняется в них нет особо смысла

* тут надо сделать оговорку, о том что на фронте и в системах с реактивностью вы можете так сделать, но это дурно пахнет(потому что инвариант будет соблюден постфактум при чтении, и может нарушить другие, а значит вы сильно свяжите чтение и запись, это может привести к рекурсивным и абсолютно не прозрачным обновлениям, если у вас не акторы или не строгая согласованность вы захлебнётесь пытаясь понять что произошло)

спасибо принял, вот эти документашки нормальные для изучения?
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice

там хорошо расписано:
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/microservice-domain-model

есть нюансы