Здравствуйте, IQuerist, Вы писали:

S>>Одни части всего этого процесса однотипные, другие, наоборот, кастомизируются до неузнаваемости, какой тут workflow?

IQ>Примитивный, но workflow.
Давайте сначала определимся, вам что главное: шашечки, или ехать?

Если поставлена цель — прикрутить сабж, то это на форумы фаулероведов надо, если ещё не вымерли такие. Если работать, то YAGNI, workflow и прочие баззворды лучше оставить в карточке для буллшит бинго и не использовать в качестве доводов.


Понимаете, паттерны, YAGNI, KISS, SOLID, UML и тыды — это инструмент. Не решение проблемы. Не рекомендация. Просто трюки, которые позволяют не делать лишнюю работу там, где она не нужна.

Использовать эти баззворды в споре считается некомильфо лет так десять, если не больше. Кто верил — наигрались уже

Серьёзно, кто-то надеется разрулить спор о строительстве дома на доводах уровня "У меня ГФОЗДЬ!!!!"?

Возвращаясь к собственно теме:
Иногда банан — это просто банан. Т.е. процесс из нескольких шагов — это именно он. Не workflow, не sequence, не сага и даже, пардон мой французский, не стратегия.

Потому что воркфлоу-движок, это совершенно особенная штука с кучей требований/ограничений.
Например:
1. Представление в виде ДКА.
2. Атомарность — биз-процесс не может зависнуть между состояниями.
3. Персистентность — процесс может висеть в определённом состоянии днями и месяцами. Разумеется, такие мелочи как пропадание электричества или пожар в здании не должны приводить процесс в состояние "всё пропало, шеф!"
4. Откат состояния — особо продвинутые воркфлоу позволяют откатить процесс на несколько шагов и направить на другую ветку отработки, при этом все внесённые на промежуточных шагах изменения также откатываются.
5. Ownership — Вовлечённые в процесс согласования сущности недопустимо изменять, что влечёт как минимум блокировку записей, как максимум — ещё и умение работать с хроникальными срезами данных.
6. Реалтайм-изменения и версионность. Сам процесс может правиться уполномоченными сотрудниками наживую, прямо в процессе отработки. При этом воркфлоу, уже прошедшие изменённое состояние должны использовать старую версию workflow.

Вы конечно можете понимать под workflow что-то своё, но это уже _не_ проблема окружающих


IQ>>>Чем по вашему БЛ принципиально отличается от "модели предметной области"? И для чего их разделять?
S>>Ну это совсем азы как бы

IQ>Т.е. преднамеренное нарушение YAGNI ?
Нет, зачем? Domain knowledge нарабатывается одновременно с анализом требований, в DDD вся первая часть этому посвящена.

Не, если предварительный анализ показал, что из требований заказчика понятны только междометия, да и то не всегда, то тут по любому придётся строить словарик перед собственно анализом требований. Но это суровая необходимость, а не подстилание соломки чтоббыло.

IQ>С азами я знаком, главная их проблема в том, что они сферические кони в ваккуме и бывают полезны только в таком же сферическом мире.
Ну да, в теории всё точно так же, как на практике, на практике — ...

На практике всё фигово. Хороших аналитиков мало, хороших бизнес-аналитиков ещё меньше, хороших книг по высокоуровневому биз-анализу практически нет. С некоторой натяжкой — только DDD, да и всё пожалуй. Да и то, только первая часть и только как направление движения, а не как готовое руководство.

Пытаться за один раз построить модель предметной области — дурь полнейшая из-за своей необъятности. А вот отделить в процессе анализа требований "так, это чтоб заказчику было приятно, рисков накосячить ноль" от "а вот эта часть будет всегда, лучше утчнить детали и сразу сделать нормально" никогда вредным не бывает