единственное что, если вы еще в начале (не в тему но все же) нужно по возможности сразу продумать и заложить такую структуру данных - которую в любой момент можно было бы легко модифицировать с минимальными затратами без потери накопленной информации и логики процессов.
Т.к. у нас небыло и нет четкого технического задания - мы потратили на структуру ровно год да и продолжаем налетать на те же грабли - говорят - хотим чтобы было так и так, спрашиваю сколько вешать в граммах - а мы не знаем думай сам, а какие свойства у вашей работы? - да откуда мы знаем
Поэтому мы и не начали с Workflow (это было невозможно) мы с большим трудом формализовали все задачи все объекты и эмулировали Workflow действиями Party
Теперь когда у нас все есть мы просто навешиваем на созданную структуру Workflow для контроля исполнения
На мой взгляд именно структура данных, объекты, свойства, диалоги и занимают 90% разработки - это все для людей, и только 10% Workflow - это для руководства.
Мы пошли именно этим путем и в качестве базы для структуры использовали объектно ориентированный подход, который по большому счету нас не подвел ни разу
ну это я так не в тему
и еще одни грабли - в самом начале мы для каждого объекта делали свои уникальные атрибуты и получили такую кашу из одинаковых по смыслу но индивидуальных для объекта атрибутов, что чуть не утонули и только через пол года удалось немного упорядочится. Сейчас у нас не более 100 общих атрибутов которые на 80% используются в каждом объекте, правда названия у них стали обобщенными - но если вести в стороне свое описание объект-атрибут и что он значит именно для этого объекта -то все в порядке. Правда с утерей этого описания в нашей структуре никто и никогда не разберется- но может это и к лучшему
