Добрый день

Возник вопрос — является ли workflow обязательные элементом бизнес логики? По моим размышлениям выходит, что вроде как является.

Кроме workflow вроде бы есть еще один часто используемый элемент бизнес логики — метаданные, может кто идентифицировал другие часто используемые элементы (организации) бизнес логики?

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

IQ>Возник вопрос — является ли workflow обязательные элементом бизнес логики? По моим размышлениям выходит, что вроде как является.

Нет. Биз-логика — это небольшая прослойка кода, которая отвечает за превращение текущих требований клиента в вызовы более остального, стабильного кода.
Workflow и метаданные — это инструменты, не сама БЛ.

IQ>Кроме workflow вроде бы есть еще один часто используемый элемент бизнес логики — метаданные, может кто идентифицировал другие часто используемые элементы (организации) бизнес логики?
Примерно с той же аргументацией можно назвать запятые обязательным элементом бизнес логики

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

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

IQ>>Возник вопрос — является ли workflow обязательные элементом бизнес логики? По моим размышлениям выходит, что вроде как является.

S>Нет. Биз-логика — это небольшая прослойка кода, которая отвечает за превращение текущих требований клиента

Имхо текущими требованиями клиента занимаются аналитики. Бизнес-логика это программные механизмы созданные программерами на основе формализованных требований к системе написанных аналитиками.

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

S>>Нет. Биз-логика — это небольшая прослойка кода, которая отвечает за превращение текущих требований клиента
IQ>Имхо текущими требованиями клиента занимаются аналитики.
Так у нас речь про код, а не про разработку вообще. И вот та часть кода, которая реализует текущие требования путём вызова остального кода — вот это и есть бизнес-логика.

IQ>Бизнес-логика это программные механизмы созданные программерами на основе формализованных требований к системе написанных аналитиками.
Это слишком общее определение. При таком раскладе в БЛ попадают разнообразные хелперы, переиспользуемые запросы в DAL и прочая редкоменяющаяся инфраструктура.

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

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

S>>>Нет. Биз-логика — это небольшая прослойка кода, которая отвечает за превращение текущих требований клиента
IQ>>Имхо текущими требованиями клиента занимаются аналитики.
S>Так у нас речь про код, а не про разработку вообще. И вот та часть кода, которая реализует текущие требования путём вызова остального кода — вот это и есть бизнес-логика.

И может ли она будучи уже целостной не реализовывать workflow?

IQ>>Бизнес-логика это программные механизмы созданные программерами на основе формализованных требований к системе написанных аналитиками.
S>Это слишком общее определение. При таком раскладе в БЛ попадают разнообразные хелперы, переиспользуемые запросы в DAL и прочая редкоменяющаяся инфраструктура.

В БЛ попадают артефакты чья реализация напрямую зависит от изменений БЛ описанной архитектором. Конечно там может быть все вами описанное теоретически за исключением "переиспользуемые запросы в DAL" т.к. это вроде бы другой layer.

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

S>>Так у нас речь про код, а не про разработку вообще. И вот та часть кода, которая реализует текущие требования путём вызова остального кода — вот это и есть бизнес-логика.
IQ>И может ли она будучи уже целостной не реализовывать workflow?

Вот вам пара кусков чистейшей БЛ:

// ТП бла-бла-бла, п. x.y.z Расчетная Сумма:
// Сумма ... берётся с учётом коэффициента учётной политики ...
var result = CoeffFromPolicy(solePolicy, someDate) * calcParams.CustomerValue
...

или

if (order.SupplyConfirmDate < order.SupplyDate) return new Validation(false, "бла-бла-бла");

Для солидности можно раздуть в пару сотен методов, которые состоят примерно из похожей логики, сам подход не меняется.
Найдёте здесь workflow?



S>>Это слишком общее определение. При таком раскладе в БЛ попадают разнообразные хелперы, переиспользуемые запросы в DAL и прочая редкоменяющаяся инфраструктура.
IQ>В БЛ попадают артефакты чья реализация напрямую зависит от изменений БЛ описанной архитектором. Конечно там может быть все вами описанное теоретически за исключением "переиспользуемые запросы в DAL" т.к. это вроде бы другой layer.

При изменении требований могут дорабатываться все слои приложения, от UI и до схемы данных. Стоит ли включать их в БЛ?

Суть в чём: в любом проекте с работающим аналитиком есть стабильная часть, отвечающая за модель предметной области заказчика и собственно БЛ, работающая поверх модели предметной области. Более того, в нормально спроектированных продуктах первая не меняются годами, почти при любых изменениях, вплоть до смены языка программирования (не теория, практика).

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

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

S>>>Так у нас речь про код, а не про разработку вообще. И вот та часть кода, которая реализует текущие требования путём вызова остального кода — вот это и есть бизнес-логика.
IQ>>И может ли она будучи уже целостной не реализовывать workflow?

S>Вот вам пара кусков чистейшей БЛ:

Думаю вы сами оцените отсутствие даже намека на целостность БЛ Под целостностью я понимаю полную реализацию полезного сценария внутри БЛ.

S>>>Это слишком общее определение. При таком раскладе в БЛ попадают разнообразные хелперы, переиспользуемые запросы в DAL и прочая редкоменяющаяся инфраструктура.
IQ>>В БЛ попадают артефакты чья реализация напрямую зависит от изменений БЛ описанной архитектором. Конечно там может быть все вами описанное теоретически за исключением "переиспользуемые запросы в DAL" т.к. это вроде бы другой layer.

S>При изменении требований могут дорабатываться все слои приложения, от UI и до схемы данных. Стоит ли включать их в БЛ?

Могут, но изменения в UI и в DB будут прорабатываться отдельно. "Заказ" на их изменение придет со стороны БЛ.

S>Суть в чём: в любом проекте с работающим аналитиком есть стабильная часть, отвечающая за модель предметной области заказчика и собственно БЛ, работающая поверх модели предметной области. Более того, в нормально спроектированных продуктах первая не меняются годами, почти при любых изменениях, вплоть до смены языка программирования (не теория, практика).

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

Сабж

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

TG>Сабж

Собс-но создание артефакта и его прохождение через набор определенных состояний, в процессе которого (прохождения) артефакт обретает собственную ценность в рамках определенного контекста.

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

S>>Вот вам пара кусков чистейшей БЛ:

IQ>Думаю вы сами оцените отсутствие даже намека на целостность БЛ Под целостностью я понимаю полную реализацию полезного сценария внутри БЛ.
Ну так типовой биз-процесс — это док на 15 страниц мелким шрифтом с кросс-отсылками на соседние документы/нормативы. И, сюрприз, он весь состоит из подобных условий — утянуть настройки отсюда, взять суммы оттуда, округлить-перемножить, сравнить с тем-то, засунуть туда-то. Одни части всего этого процесса однотипные, другие, наоборот, кастомизируются до неузнаваемости, какой тут workflow?

Того, ради чего и городят workflow — перевод в состояние x, одобрить-согласовать и перевести в состояние y, не удалось — z в типовой БЛ нет, это к СЭД-движкам.

Вот это:

Собс-но создание артефакта и его прохождение через набор определенных состояний, в процессе которого (прохождения) артефакт обретает собственную ценность в рамках определенного контекста.

не workflow, это обычный create-config-use pattern из компонентно-ориентированной разработки. На биз-процессы он натягивается очень туго, потому что "конвеер" составляет мизерную часть кода и обычно состоит из последовательности вызовов методов, обёрнутых в локальную транзакцию.

Городить из этого отдельную концепцию "бизнес как воркфлоу" можно только если вы продаёте карго-культы вроде диаграмм ios 9000.


S>>Суть в чём: в любом проекте с работающим аналитиком есть стабильная часть, отвечающая за модель предметной области заказчика и собственно БЛ, работающая поверх модели предметной области. Более того, в нормально спроектированных продуктах первая не меняются годами, почти при любых изменениях, вплоть до смены языка программирования (не теория, практика).

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

Предметная область слабо зависит от хотелок и нужд заказчика. Хошь-не-хошь, надо соблюдать требования законодательства, положения по бухучёту и прочая-прочая прочая. Атрибуты у типовых сущностей, их состав и назначение не меняется годами. Например, для ОО/контрагентов если что и менялось за эти годы, то это замена кодов ОКАТО на коды ОКТМО и мода на хранение логотипов. Такие "постоянные" вещи нет никакого смысла смешивать с БЛ, так-как во-первых они будут усложнять правку самой БЛ из-за сильной связности.
А во-вторых, т.н. domain knowledge и есть самая сильная сторона любой erp-системы. Т.к. вместо того, чтобы кодить заново _и_ бизнес процессы заказчика (уникальны) _и_ нюансы предметной области (совпадают практически всегда) достаточно просто немного подтюнить давно написанный и отлаженный код.

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

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

S>>>Вот вам пара кусков чистейшей БЛ:

IQ>>Думаю вы сами оцените отсутствие даже намека на целостность БЛ Под целостностью я понимаю полную реализацию полезного сценария внутри БЛ.
S>Ну так типовой биз-процесс — это док на 15 страниц мелким шрифтом с кросс-отсылками на соседние документы/нормативы. И, сюрприз, он весь состоит из подобных условий — утянуть настройки отсюда, взять суммы оттуда, округлить-перемножить, сравнить с тем-то, засунуть туда-то. Одни части всего этого процесса однотипные, другие, наоборот, кастомизируются до неузнаваемости, какой тут workflow?

Примитивный, но workflow.

S>Вот это:
S>

S>Собс-но создание артефакта и его прохождение через набор определенных состояний, в процессе которого (прохождения) артефакт обретает собственную ценность в рамках определенного контекста.

S>не workflow, это обычный create-config-use pattern из компонентно-ориентированной разработки. На биз-процессы он натягивается очень туго, потому что "конвеер" составляет мизерную часть кода и обычно состоит из последовательности вызовов методов, обёрнутых в локальную транзакцию.

Не знаю зачем плодить новую концепцию если все всписывается в старую.

S>Городить из этого отдельную концепцию "бизнес как воркфлоу" можно только если вы продаёте карго-культы вроде диаграмм ios 9000.

Эта конь-цепция называлась например UML. Конечно же в БЛ реального проекта кода отвечающего за workflow — доли процента. Но как мне кажется (именно поэтому и стартовал топик) весь остальной код на этом workflow завязан. Кроме конечно "отчетов" которые пример той части БЛ, которая не workflow.

S>>>Суть в чём: в любом проекте с работающим аналитиком есть стабильная часть, отвечающая за модель предметной области заказчика и собственно БЛ, работающая поверх модели предметной области. Более того, в нормально спроектированных продуктах первая не меняются годами, почти при любых изменениях, вплоть до смены языка программирования (не теория, практика).

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

Т.е. преднамеренное нарушение YAGNI ? С азами я знаком, главная их проблема в том, что они сферические кони в ваккуме и бывают полезны только в таком же сферическом мире. Если вы про DDD то имхо мало кто плодит сущности впрок. А если такая необходимость существует (например библиотека реализующая математические алгоритмы) то их пытаются выносить в отдельные фреймворки, а не делать частью бизнес логики или какой-то отдельной предметной области.

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

S>Вот это:
S>

S>Собс-но создание артефакта и его прохождение через набор определенных состояний, в процессе которого (прохождения) артефакт обретает собственную ценность в рамках определенного контекста.

S>не workflow, это обычный create-config-use pattern из компонентно-ориентированной разработки. На биз-процессы он натягивается очень туго, потому что "конвеер" составляет мизерную часть кода и обычно состоит из последовательности вызовов методов, обёрнутых в локальную транзакцию.

S>Городить из этого отдельную концепцию "бизнес как воркфлоу" можно только если вы продаёте карго-культы вроде диаграмм ios 9000.

Ну здрасте, а как же обосновывать необходимость использовать .net WWF? Самое оно. Автору надо ссылок накидать, если еще не, про WWF.

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

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

S>>Городить из этого отдельную концепцию "бизнес как воркфлоу" можно только если вы продаёте карго-культы вроде диаграмм ios 9000.

S>Ну здрасте, а как же обосновывать необходимость использовать .net WWF? Самое оно. Автору надо ссылок накидать, если еще не, про WWF.

Возможно WWF так и появился но нет, тема с WWF никак не связана.

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

S>Ну здрасте, а как же обосновывать необходимость использовать .net WWF? Самое оно. Автору надо ссылок накидать, если еще не, про WWF.
Не, если обосновать, то я и на покупку BizTalk продавить могу, оно клиенту-то надо?)))


И да, .net WF, не WWF. Засудят иначе.

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

S>>>Городить из этого отдельную концепцию "бизнес как воркфлоу" можно только если вы продаёте карго-культы вроде диаграмм ios 9000.

S>>Ну здрасте, а как же обосновывать необходимость использовать .net WWF? Самое оно. Автору надо ссылок накидать, если еще не, про WWF.

IQ>Возможно WWF так и появился но нет, тема с WWF никак не связана.

Потому как в контексте WF речь идет о построении бизнес процессов как некий workflow. Это не о то, о чем Вы спрашиваете?

Здравствуйте, 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, да и всё пожалуй. Да и то, только первая часть и только как направление движения, а не как готовое руководство.

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

Здравствуйте, 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.

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

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

S>>>>Городить из этого отдельную концепцию "бизнес как воркфлоу" можно только если вы продаёте карго-культы вроде диаграмм ios 9000.

S>>>Ну здрасте, а как же обосновывать необходимость использовать .net WWF? Самое оно. Автору надо ссылок накидать, если еще не, про WWF.

IQ>>Возможно WWF так и появился но нет, тема с WWF никак не связана.

S>Потому как в контексте WF речь идет о построении бизнес процессов как некий workflow. Это не о то, о чем Вы спрашиваете?

Не... меня вопрос волнует только с точки зрения кодирования.

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

IQ>Собс-но создание артефакта и его прохождение через набор определенных состояний, в процессе которого (прохождения) артефакт обретает собственную ценность в рамках определенного контекста.

PS "ценность", конечно для бизнеса.

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

IQ>Добрый день

IQ>Возник вопрос — является ли workflow обязательные элементом бизнес логики? По моим размышлениям выходит, что вроде как является.

IQ>Кроме workflow вроде бы есть еще один часто используемый элемент бизнес логики — метаданные, может кто идентифицировал другие часто используемые элементы (организации) бизнес логики?

А что ты понимаешь под бизнес-логикой? Это самое неопределенное понятие во всех обсуждениях. Даже сильно опережает по непонятности слово "архитектор".
Следующий вопрос: что ты понимаешь под workflow? Движок? UML описание процесса\перехода состояний? Захаржкоженный переход между состояниями в программе? Декларативное описание процесса в BPEL или другом языке?

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