В компании есть система с апрувалами. То есть электронные приказы и согласования.
Также есть 2 разных внутренних сайта, которые работают с разными базаами, но которые запускают эти апрувалы
через один апрувал сервис.
Исходники апрувал сервиса есть. Это по сути прокси, который умеет только запускать апрувал и обновлять статус апрувала.
Сейчас возникла задача, что на втором сайте после прохождения апрувала надо делать еще логику.
Самое простое это ее втащить в этот сервис, но это же апрувал сервис и не хочется туда втаскивать.
Есть вариант с джобом в базе, но тогда не будет транзакционности и логика усложняется
Кто потом с этими аппрувалами будет работать?
Аппрувал сервис заапрувил, отправил нотификацию, что approved{DocId=<id>, ApproveSendTime=now()}, а дальше кому надо пусть тот и работает.
Рефакторить аппрувал сервис, очевидно. А лучше выкосить его и воткнуть нормальный BPMN workflow engine в котором, внезапно, таких вопросов не возникает.
Здравствуйте, e.thrash, Вы писали:
ET>Сейчас возникла задача, что на втором сайте после прохождения апрувала надо делать еще логику. ET>Самое простое это ее втащить в этот сервис, но это же апрувал сервис и не хочется туда втаскивать. ET>Есть вариант с джобом в базе, но тогда не будет транзакционности и логика усложняется
ET>Какие идеи?
Я бы стал делать самое простое (втащить нужную логику в этот аппрувал сервис).
Это не просто "аппрувал сервис" это "аппрувал сервис компании X", делать его "чистым" (повторно используемым), насколько я понимаю, никому не нужно.
Также изменением текущего сервиса решается проблема миграции текущих аппрувалов в новую систему.
Я думаю об этом тоже хорошо бы подумать.