* состояние агрегата тождественно "этапу жизненного цикла"? * всегда для нового

этапа жизненного цикла заводить новый агрегат? - если не всегда, то какие критерии?

Читать про bounded context

Ну тоесть состояние агрегата это состояние агрегата, жизненный цикл это можно по user journey проследить мол на каком этапе чего делают

Не понял как ответом на вопрос о тождественности (или не тождественности) двух терминов (состояние агрегата и этап жизненного цикла агрегата) может быть указание на то что бы почитать про третий термин (bounded context) Идея состояние агрегата vs новый агрегат - мне интересна, поэтому и задаю вопросы)) Есть ситуации когда на этапе проектирования допускается ошибка и несколько объектов или процессов из реального мира, отражаются в виде одного объекта(но с разным набором статусов) в приложение . Обычно это про то что архитектор (ну или тот кто его роль выполняет) пролюбил этап аналитики по предметной области. Т.е. это про процесс проектирования. И обычно это лечится повышением квалификации того кто проектирует. Подход "агрегат для одного этапа жизненного цикла пораждает агрегат для слещующего и т.д." - имеет граничные условия? Его всегда применять надо? Как я понял тригер "короч мой поинт в том что если статусов больше двух - надо быть оч осторожными с веедением такой вещи" - т.е. если больше двух статусов нужно думать о том что бы вместо статусов были новые агрегаты ? Или есть еще другие граничные условия кроме количества двух статусов? Если что мой поинт в том - что проектировать надо лучше - если в бизнес процессах в реальном мире фигурирует инваит и юзер - то это это про инваит и юзер, а не про юзер который может быть в статусе инвайт. Но если у инвайта есть состояния про то что отправляется, получен, подтвержден - то это именно про состояния, а не про разные агрегаты. И что механистичный подход типа больше двух статусов - сразу новый агрегат - может привести к оверхеду