оно же по сути стейт машина ) описывает возможные переходы сущности по той самой бизнес-логке, даже более - вокрлоу формализует эту самую бизнес логику, что, в свою очередь помогает разговаривать с бизнесом на одном языке
на самом деле воркфлоу это не только стейт машина, там есть и другая возможность, но это не суть, насчет применения DDD не в курсе, вообще стремление перейти на стейт машины лично мне интересно из-за прочитанной статьи Шалыто об автоматном проектировании
Объекты сами должны инкапсулированно реализовывать поведение и переходы, это противоречит наличию внешнего мозга, который решает что-то за них. Да и что-то не припомню про машины состояний у Эванса и Вернона. Во-первых, workflow сильно сужает твои возможности по управлению состоянием. Ты вынужден все формализовывать математической моделью, вместо того, чтобы описывать реальные, куда более сложные процессы. А если ты и хочешь кастомный рул добавить, ты вынужден написать guard event listener, из-за чего твоя логика вытекате и растекается еще сильнее, уже за пределы конфигов. Во-вторых, очевидно, нарушает инкапсуляцию. Если ты спрашиваешь can, то значит ты можешь и не спросить, а значит, ты можешь выполнить действие в обход логики. Да и вообще Symfony Workflow требует setter-а на сущности. Получается, ты можешь засетить любое состояние в любой момент и никто тебе не запретит. Я сам очень был рад, когда появилась эта компонента в симфони. И юзал ее в хвост и в гриву две работы назад. Но, оглядываясь назад, я понимаю, что это не лучший вариант моделирования бизнес-логики.
Обсуждают сегодня