1
Проектирование / Как произвести объектную декомпозицию бизнес-процесса?
« : 06 Августа 2008, 06:47:49 »
Здравствуйте, уважаемые проектировщики!
Ситуация:
Я новичок в проектировании ПО, до сего момента только читал PEAA и GOF и практиковался на реализации некоторых паттернов. Недавно у меня появилась возможность почувствовать себя в роли проектировщика в создании небольшой системы учета заказов одной компании. Сейчас занимаюсь рисованием UML диаграмм, одна из которых (диаграмма деятельности+"плавательные дорожки") описывает алгоритм движения заказа по этапам, различные сценарии взаимодействия пользователей системы с заказом в зависимости от его типа и текущего этапа, условия перехода от этапа к этапу и так далее. В этой диаграмме я опустил мелкие ветвления, которые не важны для процесса в целом, но тем не менее корректируют небольшие участки алгоритма внутри этапов. В любом случае у каждого этапа всегда одинаковые входы и выходы.
Мои идеи:
1. В силу того, что логика всего процесса от составления заявки на оказание услуги до момента успешного оказания услуги будет впоследствии меняться и дополняться, у меня есть желание сосредоточить этот алгоритм в одном пакете классов, отделив его от более мелких алгоритмов внутри этапов.
2. Ветвления алгоритма, важные для процесса в целом, определяют несколько типичных сценариев протекания этого алгоритма. У меня таких сценариев получилось пять, но в будущем будет больше: до 10-15.
3. Логическую последовательность этапов и условия переходов от одного этапа к другому я предполагаю зашить в класс «бизнес-процесс». Все мои сценарии зашить в маленькие классы-стратегии (паттерн Стратегия), описывающие конкретную последовательность этапов. Каждый этап зашить в свой класс «этап» и в нем уже реализовывать всю логику взаимодействия объектов домена в пределах этапа.
4. идеи есть еще, но пока ограничусь этими.
Проблема:
1. Не изобретаю ли я велосипед? Если да – то ткните в нос типовым решением.
2. Стоит ли сосредотачивать логику бизнес-процесса в одном месте?
3. Декомпозицию логики бизнес-процесса на классы «бизнес-процесс», «сценарий» и «этап» я кратко описал – насколько она плоха/хороша и в каких ситуациях может себя повести (может, сейчас все просто, пока система мала)?
Очень надеюсь на конструктивную критику. Если появятся вопросы, могу снабдить пояснения UML диаграммами.
Ситуация:
Я новичок в проектировании ПО, до сего момента только читал PEAA и GOF и практиковался на реализации некоторых паттернов. Недавно у меня появилась возможность почувствовать себя в роли проектировщика в создании небольшой системы учета заказов одной компании. Сейчас занимаюсь рисованием UML диаграмм, одна из которых (диаграмма деятельности+"плавательные дорожки") описывает алгоритм движения заказа по этапам, различные сценарии взаимодействия пользователей системы с заказом в зависимости от его типа и текущего этапа, условия перехода от этапа к этапу и так далее. В этой диаграмме я опустил мелкие ветвления, которые не важны для процесса в целом, но тем не менее корректируют небольшие участки алгоритма внутри этапов. В любом случае у каждого этапа всегда одинаковые входы и выходы.
Мои идеи:
1. В силу того, что логика всего процесса от составления заявки на оказание услуги до момента успешного оказания услуги будет впоследствии меняться и дополняться, у меня есть желание сосредоточить этот алгоритм в одном пакете классов, отделив его от более мелких алгоритмов внутри этапов.
2. Ветвления алгоритма, важные для процесса в целом, определяют несколько типичных сценариев протекания этого алгоритма. У меня таких сценариев получилось пять, но в будущем будет больше: до 10-15.
3. Логическую последовательность этапов и условия переходов от одного этапа к другому я предполагаю зашить в класс «бизнес-процесс». Все мои сценарии зашить в маленькие классы-стратегии (паттерн Стратегия), описывающие конкретную последовательность этапов. Каждый этап зашить в свой класс «этап» и в нем уже реализовывать всю логику взаимодействия объектов домена в пределах этапа.
4. идеи есть еще, но пока ограничусь этими.
Проблема:
1. Не изобретаю ли я велосипед? Если да – то ткните в нос типовым решением.
2. Стоит ли сосредотачивать логику бизнес-процесса в одном месте?
3. Декомпозицию логики бизнес-процесса на классы «бизнес-процесс», «сценарий» и «этап» я кратко описал – насколько она плоха/хороша и в каких ситуациях может себя повести (может, сейчас все просто, пока система мала)?
Очень надеюсь на конструктивную критику. Если появятся вопросы, могу снабдить пояснения UML диаграммами.