Здравствуйте, 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>Полагаю маркетинговыми названиями

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