Обычно у вас есть шаги в рабочем процессе. Шаг состоит из некоторого предварительного условия (бизнес-логика скрыта от пользовательского интерфейса), некоторого взаимодействия с пользователем (пользователь вводит некоторые данные и выполняет некоторые «пользовательские действия») и публикует условия. Обычно часть взаимодействия с пользователем имеет одного или нескольких выбранных пользователем «существующих», и каждый выход состоит из своего собственного пост-условия (обычно каждый выход пользователя имеет свою собственную бизнес-логику в зависимости от значения выхода из шага). Выход из навигации для перехода к следующему шагу. Иногда вы можете выполнять полностью автоматические шаги (например, использовать какой-либо внешний источник данных, вызывать какой-либо веб-сервис, выполнять важные вычисления и т. Д.).
Если ваш рабочий процесс прост, вы можете реализовать его как набор классов, представляющих каждый шаг, и конфигурация порядка шагов может быть помещена в XML. Когда ваш рабочий процесс будет становиться все больше и больше, может быть разумно искать какой-либо механизм рабочего процесса (я думаю, что обсуждение механизмов WF выходит за рамки этого вопроса).
Одна важная вещь - шаги могут быть ортогональными, но их сложнее проектировать. Если ваши шаги зависят друг от друга, лицо, конфигурирующее рабочий процесс и порядок шагов, должно быть полностью осведомлено о таких зависимостях (например, шаг адреса пользователя, вероятно, будет зависеть от шага создания объекта пользователя, а удаление шага создания объекта пользователя из рабочего процесса приведет к попытке для доступа к несуществующему объекту).