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

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

S>>>Так у нас речь про код, а не про разработку вообще. И вот та часть кода, которая реализует текущие требования путём вызова остального кода — вот это и есть бизнес-логика.
IQ>>И может ли она будучи уже целостной не реализовывать workflow?

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

Думаю вы сами оцените отсутствие даже намека на целостность БЛ Под целостностью я понимаю полную реализацию полезного сценария внутри БЛ.

S>>>Это слишком общее определение. При таком раскладе в БЛ попадают разнообразные хелперы, переиспользуемые запросы в DAL и прочая редкоменяющаяся инфраструктура.
IQ>>В БЛ попадают артефакты чья реализация напрямую зависит от изменений БЛ описанной архитектором. Конечно там может быть все вами описанное теоретически за исключением "переиспользуемые запросы в DAL" т.к. это вроде бы другой layer.

S>При изменении требований могут дорабатываться все слои приложения, от UI и до схемы данных. Стоит ли включать их в БЛ?

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

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

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

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

S>>>Так у нас речь про код, а не про разработку вообще. И вот та часть кода, которая реализует текущие требования путём вызова остального кода — вот это и есть бизнес-логика.
IQ>>И может ли она будучи уже целостной не реализовывать workflow?

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

Думаю вы сами оцените отсутствие даже намека на целостность БЛ Под целостностью я понимаю полную реализацию полезного сценария внутри БЛ.

S>>>Это слишком общее определение. При таком раскладе в БЛ попадают разнообразные хелперы, переиспользуемые запросы в DAL и прочая редкоменяющаяся инфраструктура.
IQ>>В БЛ попадают артефакты чья реализация напрямую зависит от изменений БЛ описанной архитектором. Конечно там может быть все вами описанное теоретически за исключением "переиспользуемые запросы в DAL" т.к. это вроде бы другой layer.

S>При изменении требований могут дорабатываться все слои приложения, от UI и до схемы данных. Стоит ли включать их в БЛ?

Могут, но изменения в UI и в DB будут прорабатываться отдельно. "Заказ" на их изменение придет со стороны БЛ.

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

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