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

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

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

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

Вот это:

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

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

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


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

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

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