@fes0r  i Google it .. m'y problem IS i need to validate request json data if you now how help me

first of all, you didn't mention it in you question, you just want "angular symfony example". Second - google that that - "how to validate json request symfony"

@fes0r I find validation with form and validation with rules... Never mind

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

Что бы понять о какой пользе я говорю надо задаться вопросом "а нахер вообще все это". Мы хотим разделять и изолировать разные части логики для:

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

То есть одно из ключевых вещей в том "как дробить" - это "где придется менять и какие решения принимать". На это два фактора основных влияют - "кто пользуется" и "true invariants" Последнее причем тоже сильно привязано к "для чего этот инвариант нужен". Принятие решений часто стыкуется с какими-то этапами процесса через который проходят вещи в твоей системе.

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

Внутри этапа могут быть свои стэйт транзишены и т.д. могут быть свои инварианты которые нужны именно для этого этапа и т.д. Разные этапы - разные операции.

То есть "этап жизненного цикла" тут это именно этап процесса который ты моделируешь.

опять же - основной профит это возможность "сформулировать цель процесса, выделить его этапы на high level, рассадить разработчиков на каждый этап и дальше они уже каждый свой этап исследуют, знают кто каким этапом занимается и т.д. Вероянтность что человеку на этап 1 надо будет много взаимодействовать с людьми на этапе 5 минимальна, ну и они вкурсе что где-то 20% времени надо будет взаимодействовать с людьми на соседних этапах.

За счет этого можно масштабировать процесс разработки.

разумеется если у тебя процессы строятся по принципу "аналитик нам требования в джирке пишет а архитект рисует диаграмки" - то смысла в этом уже не столь много так как ты уже выбрал для процессов ботлнеки в виде этих самых аналитиков и архитектов.

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

Благодарю за ответ. В таком изложение ваш взгляд на статусы vs новые агрегаты понятен.  Сам придерживаюсь аналогичных взглядов.

казалось бы, простой вопрос - а целая наука ))

а если работают по заказу всегда одни и теже люди

вопрос совсем не простой

если продолжить тему агрегатов, почему рекомендуется использовать звязи не прямыми ссылки, а только id, если мы используем агрегат внутри одной системы - зачем? Согласна если нужна связь на другой агрегат в другом контексте, но внутри агрегата, и на его дочерние? врядле они будут находиться в другой системе или микросервисе

Очень нужны разрабы мидлы и сеньоры на Symfony, вилка 100к-300к в зависимости от уровня 😢

бери меня

полностью

Всем нужны(

А у тебя опыт в коммерческих проектах есть?

да, люблю деньги считать ))