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

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

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

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

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

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

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

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

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

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

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

Спасибо, что потратили время. Мощь вашего опыта я ценил Много слов, но workflow останется workflow — "четко определенные состояния и переходы между ними" и без всех этих украшений типа "отката состояний".

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

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

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

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