Здравствуйте, 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 и до схемы данных. Стоит ли включать их в БЛ?

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