Добрый день

Возник вопрос — является ли 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 такая логика не попадет.

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

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

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

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

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

G>А что ты понимаешь под бизнес-логикой?

Имхо код главным источником изменений которого является аналитик.

G>Это самое неопределенное понятие во всех обсуждениях. Даже сильно опережает по непонятности слово "архитектор".

Это да.

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

Имхо максимально декларативно определенные состояния (артефактов системы) и переходы между ними.

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

Результатом работы системы для бизнеса являются сущности имеющие собственную ценность для бизнеса. Валидация вводимых данных имхо "собственной ценности для бизнеса" не имеет, хоть и может является элементом реализации бизнес логики.

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

G>>А что ты понимаешь под бизнес-логикой?
IQ>Имхо код главным источником изменений которого является аналитик.
А если нет аналитика? Бизнес-логики тоже нет?

G>>Следующий вопрос: что ты понимаешь под workflow? Движок? UML описание процесса\перехода состояний? Захаржкоженный переход между состояниями в программе? Декларативное описание процесса в BPEL или другом языке?
IQ>Имхо максимально декларативно определенные состояния (артефактов системы) и переходы между ними.
Такое используется крайне нечасто.

IQ>Результатом работы системы для бизнеса являются сущности имеющие собственную ценность для бизнеса. Валидация вводимых данных имхо "собственной ценности для бизнеса" не имеет, хоть и может является элементом реализации бизнес логики.
Валидация данных имеет офигенную ценность для бизнеса, так как превращает неструктурированные данные в структурированные. Банальный пример — CRM. Важнейшая часть — контактные данные, без валидации email это просто строка текста, которая не имеет ценности для бизнеса. Если email введен корректно, то на базе этих данных можно строить маркетинг.

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

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

G>>>А что ты понимаешь под бизнес-логикой?
IQ>>Имхо код главным источником изменений которого является аналитик.
G>А если нет аналитика? Бизнес-логики тоже нет?

Бизнес логики часто нет и при наличии аналитика

G>>>Следующий вопрос: что ты понимаешь под workflow? Движок? UML описание процесса\перехода состояний? Захаржкоженный переход между состояниями в программе? Декларативное описание процесса в BPEL или другом языке?
IQ>>Имхо максимально декларативно определенные состояния (артефактов системы) и переходы между ними.
G>Такое используется крайне нечасто.

Это да, часто состояния и переходы размазаны по коду. Но это ведь не значит что к этому нужно стремиться?

IQ>>Результатом работы системы для бизнеса являются сущности имеющие собственную ценность для бизнеса. Валидация вводимых данных имхо "собственной ценности для бизнеса" не имеет, хоть и может является элементом реализации бизнес логики.
G>Валидация данных имеет офигенную ценность для бизнеса, так как превращает неструктурированные данные в структурированные.

Валидация вроде бы ничто ни во что не превращает, а лишь пропускает ввод данных по формальным признакам или не пропускает.

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

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

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

G>>>>А что ты понимаешь под бизнес-логикой?
IQ>>>Имхо код главным источником изменений которого является аналитик.
G>>А если нет аналитика? Бизнес-логики тоже нет?
IQ>Бизнес логики часто нет и при наличии аналитика
Это правда, но на вопрос не отвечает. В отсутствии аналитика как определяется бизнес-логика?

G>>>>Следующий вопрос: что ты понимаешь под workflow? Движок? UML описание процесса\перехода состояний? Захаржкоженный переход между состояниями в программе? Декларативное описание процесса в BPEL или другом языке?
IQ>>>Имхо максимально декларативно определенные состояния (артефактов системы) и переходы между ними.
G>>Такое используется крайне нечасто.
IQ>Это да, часто состояния и переходы размазаны по коду. Но это ведь не значит что к этому нужно стремиться?
Не факт что нужно. То, о чем ты пытаешься говорить, называется DSL. Есть теория, что любая задача может быть сведена к тривиальной, путем изобретения подходящего DSL-я. Проблема в том, что сама по себе разработка DSL_я и поддержка его — немаленький проект. Поэтому на практике используются eDSL — наборы функций, похожие на язык программирования. Советую и вам смотреть в этом направлении.

Workflow движки — частный случай DSL, заточенный на оркестрацию сервисов.


IQ>>>Результатом работы системы для бизнеса являются сущности имеющие собственную ценность для бизнеса. Валидация вводимых данных имхо "собственной ценности для бизнеса" не имеет, хоть и может является элементом реализации бизнес логики.
G>>Валидация данных имеет офигенную ценность для бизнеса, так как превращает неструктурированные данные в структурированные.
IQ>Валидация вроде бы ничто ни во что не превращает, а лишь пропускает ввод данных по формальным признакам или не пропускает.
Валидация дает гарантию. Это самое важное. Если у тебя код гарантирует, что в строке email — на этом можно строить логику.

Здравствуйте, gandjustas, Вы писали:
IQ>>Бизнес логики часто нет и при наличии аналитика
G>Это правда, но на вопрос не отвечает. В отсутствии аналитика как определяется бизнес-логика?

Привлечение аналитика — это попытка организации канала с заказчиком как источником фактов о задаче (источник представлений о бизнесе).

G>>>>>Следующий вопрос: что ты понимаешь под workflow? Движок? UML описание процесса\перехода состояний? Захаржкоженный переход между состояниями в программе? Декларативное описание процесса в BPEL или другом языке?
IQ>>>>Имхо максимально декларативно определенные состояния (артефактов системы) и переходы между ними.
G>>>Такое используется крайне нечасто.
IQ>>Это да, часто состояния и переходы размазаны по коду. Но это ведь не значит что к этому нужно стремиться?
G>Не факт что нужно. То, о чем ты пытаешься говорить, называется DSL.

Нет. Я говорю именно о workflow, как базовом шаблоне реализации операций в системе.

>>>Есть теория, что любая задача может быть сведена к тривиальной, путем изобретения подходящего DSL-я. Проблема в том, что сама по себе разработка DSL_я и поддержка его — немаленький проект. Поэтому на практике используются eDSL — наборы функций, похожие на язык программирования. Советую и вам смотреть в этом направлении.

Я не до конца понимаю энтузиазм по поводу DSL. Из него сделали фетиш, не разобравшись в проблеме. А проблема такова, что в начале работы над системой мы имеем ряд детально проработанных довольно абстрактных и понятных подсистем — DAL, UI, например .net framework и т.д. и нулевое ядро бизнес логики. И в попытках создания DSL (имхо всегда избыточных) мы пытаемся заранее оградить себя от влияния SQL, ajax, html и т.д. DSL это всего лишь набор псевдонимов для функций системы и ее entity (структур данных). Все то же самое можно реализовать через декларативные шаблоны (типа fluent interface) и несложные приемы организации кода.

G>Workflow движки — частный случай DSL, заточенный на оркестрацию сервисов.

IQ>>>>Результатом работы системы для бизнеса являются сущности имеющие собственную ценность для бизнеса. Валидация вводимых данных имхо "собственной ценности для бизнеса" не имеет, хоть и может является элементом реализации бизнес логики.
G>>>Валидация данных имеет офигенную ценность для бизнеса, так как превращает неструктурированные данные в структурированные.
IQ>>Валидация вроде бы ничто ни во что не превращает, а лишь пропускает ввод данных по формальным признакам или не пропускает.
G>Валидация дает гарантию. Это самое важное. Если у тебя код гарантирует, что в строке email — на этом можно строить логику.

увы гарантий валидация email не дает. Т.к. я спокойно могу указать чужой.

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

G>Workflow движки — частный случай DSL, заточенный на оркестрацию сервисов.
Забейте. У топикстартера абсолютно своё понимание термина workflow, никакого отношения к общепринятому оно не имеет.
Менять мнение человек не хочет, смысл спорить?

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

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

G>>Workflow движки — частный случай DSL, заточенный на оркестрацию сервисов.
S>Забейте. У топикстартера абсолютно своё понимание термина workflow, никакого отношения к общепринятому оно не имеет.
S>Менять мнение человек не хочет, смысл спорить?

Взрослые люди, как правило общаются для того, чтобы узнать чужое мнение, а не навязать свое.

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

IQ>Взрослые люди, как правило общаются для того, чтобы узнать чужое мнение, а не навязать свое.

Ну так вам уже два человека прямым текстом говорят, что вы под workflow понимаете что-то своё.

Это всё равно что начинать с "всякая ли машина самосвал?" и закончить "ну, в багажнике тоже есть что-то от самосвала"

Я не знаю, как бы понятней объяснить, но за вот этим:

Имхо максимально декларативно определенные состояния (артефактов системы) и переходы между ними.

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

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

О чём спор —

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

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

IQ>>Взрослые люди, как правило общаются для того, чтобы узнать чужое мнение, а не навязать свое.

S>Ну так вам уже два человека прямым текстом говорят, что вы под workflow понимаете что-то своё.

Я вас все таки не понимаю. Хорошо — http://www.workflowpatterns.com/patterns/control/basic/wcp1.php

S>Я не знаю, как бы понятней объяснить, но за вот этим:
S>

S>Имхо максимально декларативно определенные состояния (артефактов системы) и переходы между ними.

S>должна скрываться тонна инвариантов,

Так и есть. Свобода почти полная.

S>Иначе толка от декларативности никакого нет

Конечно же есть. Главная цель декларативности (имхо неплохой пример fluent interface) — создание "контекста" и соотв. ограничение доступных инвариантов.

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

А без workflow этого не происходит?

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


S>>Ну так вам уже два человека прямым текстом говорят, что вы под workflow понимаете что-то своё.

IQ>Я вас все таки не понимаю. Хорошо — http://www.workflowpatterns.com/patterns/control/basic/wcp1.php
Гхмм... вы серьёзно не знаете, чем workflow от workflow patterns отличается? Не прикалываетесь?

Если на пальцах, то это как сравнивать кошку и раскраску для дошколят "породы кошек". Т.е. или вы троллите, или действительно не разбирались, что такое workflow и как он на практике реализуется.

Workflow — это комбинация из формализованного описания процесса (как правило, в виде ДКА) и кучи чорной магии инфраструктуры, которая и позволяет этому описанию работать. Одного без другого не бывает.

Wf patterns — это всего-навсего примитивы для диаграммы последовательностей — sequence/loop/fork-merge etc. Без инфраструктуры (см предыдущий пункт, и заодно — списочек по вашей ссылке) они все сводятся к базовым конструкциям любого императивного языка и стартовый вопрос превращается в что-то типа "всякая ли БЛ содержит циклы?"
Я надеюсь, вы не это имели в виду

P.S. Сайт, что вы использовали для пруфа тож очень странный. Точнее, не странный, а типичный продукт с какой-нибудь конференции по паттернам. UPD. Угадал кстати
Куча трюизмов пополам с неплохими статьями. Да, вот эта фигня под капотом нужна. И да, это ещё не самый треш

Ну и обновить бы его. Там продукты выбраны, которые даже мамонты не помнят. Enhydra Shark 2? Блин, да оно в 2006м емнип зарелизилось. iPlanet — вообще привет из 2001го. Странные люди.

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

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


S>>>Ну так вам уже два человека прямым текстом говорят, что вы под workflow понимаете что-то своё.

IQ>>Я вас все таки не понимаю. Хорошо — http://www.workflowpatterns.com/patterns/control/basic/wcp1.php
S>Гхмм... вы серьёзно не знаете, чем workflow от workflow patterns отличается? Не прикалываетесь?

Полагаю маркетинговыми названиями И честно говоря, углубляться в изучении узко специфичной терминологии связанной с вашим сугубо личным опытом я не планировал. Сегодня вы думаете так, а завтра эдак Изначальный вопрос то в сущности был не о том.

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

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

Троллите т.е. Ок, из топика ушёл.