-= Без отзыва =-

Проверьте со всей строгостью. Знаю, что на втором уроке есть ответы, но их не смотрел, честное слово)

-= Без отзыва =-

-= Без отзыва =-

-= Без отзыва =-

что то нет вебинара на страице ...

Отлично! Рассказано доступно, понятным языком, хорошо подобраны примеры. Редкий случай когда сразу все понятно. Спасибо!

Мякотка начинается где-то с 13:00. В целом вполне комфортно смотреть на 1.25 скорости.
Было бы очень удобно если бы к видео шли таймкоды с кратким содержанием ролика.


В целом меня вполне устраивает Symfony Workflow Component. Сейчас он стал очень навороченным.
Для более сложных Workflow отлично подходит упомянутый в видео BPMN, например Camunda. Для банков это вообще must have и best practice.


Метод докладчика похож на изобретение связки Command + Command Bus + Symfony Workflow Component + немного Event Sourcing без снапшотов, но с тотальным игнорированием принципов SOLID.

Очень странно, что автор говорит о статусах доставки и оплаты в контексте одного бизнес объекта, хотя по хорошему это отдельные иерархии объектов со своим набором статусов.
Наверное в этом и главная проблема — попытка засунуть статусы одних объектов в систему статусов других.
В рамках бизнеса доставку и оплату могут осуществлять вообще разные подразделения и обрабатывать свои действия в разных информационных системах.

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


Стоит держать в голове, что бизнес процессы — не константы. Так же и статусы — не константа.

Сегодня статус расчитывается одним способом, завтра — другим, а для определённого типа клиентов — третим.
Очень быстро функции рассчёта статусов разрастутся до неприличной стожности. А также статусы могут как появляться, так и удаляться.

А самое смешное, что правила могут поменяться насколько, что могут появляться сущнсти с кривыми статусами.
Например, часть заказа была обработана по старым правилам рассчёта статусов, а вторая половина заказа — по новым.
Тут конечно на помощь приходит BPMN с его версионированием Workwlow, чтобы каждый объект обрабатывался в рамках одной версии бизнес-процесов.
Но если версионирования не было, то могут появиться доставленные, но не оплаченные закрытые заказы и прочие аномалии, например, оплаченный, но не созданный заказ.

А ведь ещё не стоит забывать про «компенсирующие транзакции», отменяющие ранее зафиксированные действия.
Например, платёжка сказала что счёт оплачен, а через день выясняется что в палётжке был глюк и оплаты на самом деле не было или клиент платёж отозвал.
По принципам Event Sourcing нельзя удалить или изменить запись лога, а нужно создать новую запись её отменяющую с указанием подробностей — компенсирующую транзакцию.
И тогда в логику функции оплаченного статуса добавляется проверка на отсутствие всевозможных компенсирующих транзакций, что в целом не так плохо.
А если архитектор этой системы решит сделать отдельные статусы для каждой ситуации компенсирующей транзакции, тогда в коде придётся проверять не только статус оплаты, но и всех возможных статусов её отмены.

А если захочется сделать выборку из БД объектов в определённом статусе? Придётся дублировать и поддерживать эту логику в БД.
И будет очень смешно, когда логика в БД по каким-то причинам станет расходиться с логикой в коде. А это рано или поздно начнёт случаться.

-= Без отзыва =-

-= Без отзыва =-