ну в мускуле значит с этим попроще

ну в целом в pg тоже "добавить" значение в конец вроде не проблема...

Adding members in the middle of the list causes renumbering of existing members, which requires a table copy.

таки нужно(

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

Приложу сюда, а то потом опять искать #ENTITIES_vs_VO

ну в целом берешь и делаешь case да, для репортов норм.

Только важно - табличка у тебя будет не на статус а на "этап жизненного цикла". Это все ж чуть другое.

Например есть у тебя запись к врачу. У тебя там есть статусы "запланировано", "пришел", "заполнил доки", "ожидает врача" и т.д. и т.п. Тут скорее даже идея что у тебя "этапы" эти мэпятся каждый на свой контекст и именно по этой причине важно дробить на разные агрегаты.

Есть чекин, есть интейк, есть там некая фаза ожидания, потом еще могут быть фазы и каждая - свой контекст со своими персонами которые заинтересованы и т.д. каждый этап можно своей команде дать и т.д. аля activity в value chain

Если речь идет о статусе вроде pending, in progress, done - то да, в этом не оч много смысла. Речь идет больше о том когда разные статусы ложатся в границы разных контекстов и влияют на разных людей. Там у тебя в целом вот этой ситуации что "тебе надо ждя каждой достать последний статус" просто с точки зрения workflow не особо нужны.

Эванс много говорил что "зря я про сущности втирал в своей синей книжке, люди не поняли что контексты важнее"

Ну вот тут и начинается боль - а как правильно разделить. А так - все привыкли к одной табличке orders и графу статусов, особенно если ещё и комплектация / доставка сложная

согласен

вообще ключевая мысль - есть значения и есть стэйт. Что бы стэйт можно было менять тебе нужна какая-то идентити стэйта. Именно по этому появляется необходимость в таком разделении на "сущности" (стэйт + идентити) и "значения" которые что бы они оставались значениями не должны меняться и обладать своим жизненным циклом

logical cohesion не зря называют logical. "все что про заказ в заказ" - логично же. и не важно что это чуть лучше "случайного"

это event sourcing на минималках?)))

Не, вообще не пересекаются эти вещи

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

Читать про bounded context

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

Не понял как ответом на  вопрос о тождественности  (или не тождественности) двух терминов (состояние агрегата и этап жизненного цикла агрегата) может быть  указание на то что бы почитать про третий термин (bounded context)

Идея состояние агрегата vs новый агрегат - мне интересна, поэтому и задаю вопросы))

Есть ситуации когда на этапе проектирования допускается ошибка и несколько объектов или процессов из реального мира, отражаются в виде одного объекта(но с разным набором статусов) в приложение .
Обычно это про то что архитектор (ну или тот кто его роль выполняет) пролюбил этап аналитики по предметной области.
Т.е. это про процесс проектирования. И обычно это лечится повышением квалификации того кто проектирует.

Подход  "агрегат для одного этапа жизненного цикла пораждает агрегат для слещующего и т.д." - имеет граничные условия?
Его всегда применять надо? Как я понял тригер "короч мой поинт в том что если статусов больше двух - надо быть оч осторожными с веедением такой вещи" - т.е. если больше двух статусов нужно думать о том что бы вместо статусов были новые агрегаты ? Или есть еще другие граничные условия кроме количества двух статусов?

Если что мой поинт в том - что проектировать надо лучше - если в бизнес процессах в реальном мире фигурирует инваит и юзер - то это это про инваит и юзер, а не про юзер который может быть в статусе инвайт. Но если у инвайта есть состояния про то что отправляется, получен, подтвержден - то это именно про состояния, а не про разные агрегаты. И что механистичный подход типа больше двух статусов - сразу новый агрегат - может привести к оверхеду

Hi Friends i need angular symfony full stack Real word application Source code

Then google it