Очень долго волновал вопрос про "программирование бизнес процессов".
Как правильно подойти к этому вопросу......
Ирония судьбы.
Я столкнулся с такой задачей на практике.
Нужно было запрограммировать БП:
Есть проект, который попадает на утверждение в главное подразделение, которое направляет этот проект уже в дополнительные службы (5 штук). Каждая служба выставляет статус (утвержден, на доработку, отказать). Так же по проекту должны быть логи. Кто и когда выставил какой статус проекту. И отставлять комментарии к проекту.
Так же, после того как все службы выставили статусы, проект должен вернуться обратно в главное подразделение. И дальше уже решается судьба проекта. И важный момент, что этот БП может быть зациклен до бесконечности.
В итоге проект либо утверждают, либо отправляют на доработку автору, либо снова отправляют в службы(то есть зацикливание процесса).
Я то все сделал, но мне не понравилась моя реализация. Потому что у меня очень много условий вышло на проверки статусов и зацикливание....
Я понимаю, что есть паттерны проектирования, но я не нашел применение этих паттернов для этой задачи .... Скорее всего из-за отсутствия опыта программирование самих БП. Поэтому кроме как условий у меня ничего и не получилось. И все эти условия были запрограммированы внутри контроллера.
В моем представлении, это я уже сейчас провожу работу над ошибками, либо надо было использовать какой-то поведенческий паттерн, либо вынести все эти условия в отдельный класс или компонент.
Как вы программируете БП? И как программировать, когда эти БП более сложные чем мой пример?
К тому же моя реализация очень хрупкая. Если потребуется внести еще какой-то процесс внутри текущего БП, условий будет еще больше.
Антон Р., Надо было подписать ......
Там параллельное согласование.
То есть главное подразделение сразу отправляет во все службы, и каждая из них отдельно согласовывает.
Когда-то очень давно мне нужно было смоделировать технологическую линию и сделать это достаточно гибко. Причем на ЛИСПе. Тогда я решил проблему описания пути заготовок через этапы производства через механизм сообщений. Объекты, представляющие собой единицу технологического процесса (штамповка, окраска, сварка и т.д.), передавали между собой сообщения-заготовки. Соответственно, вся логика обработки была локализована в каждом объекте. Он мог принять сообщение, мог отказаться (если еще не завершена обработка предыдущего), мог перенаправить. Соответственно, если объект принимал сообщение, то дальше уже по своим внутренним правилами генерировал новые сообщения (скажем, лист стали мог превратиться в дюжину вырубленных заготовок) и потом пытался отправить их дальше согласно таблице маршрутизации (точнее, списку маршрутов, так как это все-таки был ЛИСП :)). В итоге все работало красиво и слаженно как оркестр и можно было наглядно видеть где оборудование простаивает, а где копится невыполненная работа.
Возможно, в вашем случае можно сделать что-то похожее.
Я помню что для похожих ситуаций можно было использовать шаблон Состояние. Его фишка в том, что можно задать валидную цепочку состояний, а само состояние инкапсулируется в классах
