Здравствуйте, 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 то имхо мало кто плодит сущности впрок. А если такая необходимость существует (например библиотека реализующая математические алгоритмы) то их пытаются выносить в отдельные фреймворки, а не делать частью бизнес логики или какой-то отдельной предметной области.