![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenИз переписки в группе agile-ukraine.
Бизнес-логика — это то, что останется от клиентских задач, если убрать компьютеры.
Всё равно у заказа будут строки, НДС будет начисляться по тем же правилам, а кредит нельзя будет выдавать, если кредитуемый сидел в тюрьме.
Бизнес-логика выводится из use cases, а в use cases не следует упоминать компьютеры.
"Инфраструктурой" же я назваю библиотеки, которые использует само приложение. Можно взять любое другое название для layer-а, например, по фаулеровским PoEA, "сервисы", "интеграция", или "вспомогательный слой UI + доступ к данным".
Все эти вещи повторяются от приложения к приложению, с разными вариантами.
[Ядро системы 1C? Или Management Console для Windows? ... задают инвариантное поведение базированных на них систем]
Это не бизнес-логика, это именно инфраструктура. Библиотека, которая сама не содержит ничего, понятного и непосредственно нужного конечному пользователю. Но которая позволяет НАД ней построить какую-то логику, и немного сэкономить на общей функциональности.
Для меня бизнес-логика - более узкое понятие. Это тот алгоритм, который нужно выполнить пользователю: дефрагментировать диск, просуммировать и проверить проводки. В этих ядра нет кода, который это делает, есть только функции, которые помогают построить GUI или DAL.
Они и есть сервисы или инфраструктура.
Если выбрать такое деление на слои, то легче будет отделить слой "пользовательских алгоритмов". И когда эти алгоритмы (бизнес-логика) поменяется, инфраструктура не будет цепляться и мешать менять логику.
Бизнес-логика — это то, что останется от клиентских задач, если убрать компьютеры.
Всё равно у заказа будут строки, НДС будет начисляться по тем же правилам, а кредит нельзя будет выдавать, если кредитуемый сидел в тюрьме.
Бизнес-логика выводится из use cases, а в use cases не следует упоминать компьютеры.
"Инфраструктурой" же я назваю библиотеки, которые использует само приложение. Можно взять любое другое название для layer-а, например, по фаулеровским PoEA, "сервисы", "интеграция", или "вспомогательный слой UI + доступ к данным".
Все эти вещи повторяются от приложения к приложению, с разными вариантами.
[Ядро системы 1C? Или Management Console для Windows? ... задают инвариантное поведение базированных на них систем]
Это не бизнес-логика, это именно инфраструктура. Библиотека, которая сама не содержит ничего, понятного и непосредственно нужного конечному пользователю. Но которая позволяет НАД ней построить какую-то логику, и немного сэкономить на общей функциональности.
Для меня бизнес-логика - более узкое понятие. Это тот алгоритм, который нужно выполнить пользователю: дефрагментировать диск, просуммировать и проверить проводки. В этих ядра нет кода, который это делает, есть только функции, которые помогают построить GUI или DAL.
Они и есть сервисы или инфраструктура.
Если выбрать такое деление на слои, то легче будет отделить слой "пользовательских алгоритмов". И когда эти алгоритмы (бизнес-логика) поменяется, инфраструктура не будет цепляться и мешать менять логику.
Tags: