01.11.2017
20:30

Вебинар закончился

Зарегистрируйтесь или войдите, чтобы получить доступ к записи вебинара

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

Вы делаете интернет-магазин, у вас есть заказы и статусы заказов? Это бизнес-процесс. Задачи в трекере? Сделка с клиентом в CRM? Это всё тоже бизнес-процессы!

Как правильно построить универсальную, гибкую и расширяемую архитектуру бизнес-процессов - расскажет этот вебинар

Дата

Вебинар проводился 01.11.2017. В данный момент он уже закончен.

Ведущий

Вебинар проводил преподаватель Академии программирования "ProfIT" Степанцев Альберт

Участники

Федоров Максим, Хижняк Павел, Кузенко Дмитрий, Фролов Максим, Ульянов Сергей, Озерская Анна, Мамонов Виктор, Чуриков Михаил, Кульба Александр, Фомин Иван, Алексей, Ермолаев Алексей, Андрей, Жежель Роман, Михаил, Рулёв Александр, Силинский Дмитрий, Бурак Павел, Жуков Евгений, Лисиенко Эдуард, Влад, Seckhovich Serega, Гилёв Евгений, Rodionov Dmitry, Кравец Петр, Захарян Руслан, Низамов Олег, Kudriashova Yuliia, Laizans Gints, Шаталов Александр, Шаталов Александр, Шаронов Антон, Кондратский Богдан, Молочников Игорь, Volodin Victor, Чаус Никита, Брут-Бруляко Александр, Мархай Андрей, Smykovskyi Kyrylo, Asfan Ayrat, Доминатор Альбус, Маловичко Сергей, anna-aevum@bk.ru, Дмитриева Алиса

Видеозапись

Видеозапись и другие материалы доступны только участникам вебинара после его завершения.

Оценки и отзывы

Мякотка начинается где-то с 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 нельзя удалить или изменить запись лога, а нужно создать новую запись её отменяющую с указанием подробностей — компенсирующую транзакцию.
И тогда в логику функции оплаченного статуса добавляется проверка на отсутствие всевозможных компенсирующих транзакций, что в целом не так плохо.
А если архитектор этой системы решит сделать отдельные статусы для каждой ситуации компенсирующей транзакции, тогда в коде придётся проверять не только статус оплаты, но и всех возможных статусов её отмены.

А если захочется сделать выборку из БД объектов в определённом статусе? Придётся дублировать и поддерживать эту логику в БД.
И будет очень смешно, когда логика в БД по каким-то причинам станет расходиться с логикой в коде. А это рано или поздно начнёт случаться.
Доминатор Альбус
17.07.2021
Без отзыва
Молочников Игорь
12.09.2020
Отличный вебинар, впрочем, как и все!
Хотелось бы посмотреть вебинар, в котором бы рассказали про полный цикл работы над проектом, так сказать, от получения задания от заказчика до выхода готового продукта. Некий усреднённый алгоритм. На что обращать особое внимание, какие подводные камни. Особенности разработки в полноценной команде и при работе 1-2 человека над проектом. Какими минимальными знаниями должны обладать люди, чтобы успешно завершить проект. Надеюсь, я внятно изложил свои пожелания.
И ещё раз благодарю за этот и другие ваши вебинары, всегда очень познавательно.
Жуков Евгений
09.11.2017
Без отзыва
Гилёв Евгений
03.11.2017
Без отзыва
Ермолаев Алексей
03.11.2017
Без отзыва
Федоров Максим
02.11.2017
Вебинар, был весьма познавательным.
С интересными примерами и пояснениями.
Главное что, Альберт все это знает не понаслышки.
Спасибо, было интересно.
Фомин Иван
02.11.2017