Бизнес-логика в программном обеспечении

Введение

Концепция в компьютерном программном обеспечении
В компьютерном программном обеспечении бизнес-логика или логика предметной области — это часть программы, кодирующая реальные бизнес-правила, определяющие, как данные могут создаваться, храниться и изменяться. Она отличается от остальной части программного обеспечения, которая может быть связана с деталями более низкого уровня, такими как управление базой данных, отображение пользовательского интерфейса, системная инфраструктура или, в целом, взаимодействие различных частей программы.

Бизнес-логика и уровни/слои

Бизнес-логика может находиться в любом месте программы. Например, для определённого формата адреса можно создать таблицу базы данных, в которой столбцы будут точно соответствовать полям, определённым в бизнес-логике, и добавить проверки типов, чтобы исключить добавление недопустимых данных. Бизнес-логика часто изменяется. Например, набор допустимых форматов адресов может измениться, когда интернет-магазин начнёт доставку товаров в новую страну. Поэтому часто желательно, чтобы код, реализующий бизнес-логику, был относительно изолированным или слабо связанным. Это повышает вероятность того, что изменения в бизнес-логике потребуют небольшого количества изменений кода, только в одной части программы. Удалённый, но тесно связанный код также увеличивает риск того, что программист внесёт лишь часть необходимых изменений и пропустит часть системы, что приведёт к некорректной работе. Многоуровневая архитектура формализует такое разделение, создавая слой бизнес-логики, отделённый от других уровней или слоёв, таких как слой доступа к данным или уровень обслуживания. Каждый слой "знает" лишь минимальный объём кода в других слоях – ровно столько, сколько необходимо для выполнения задач. Например, в парадигме "модель-представление-контроллер" слои контроллера и представления могут быть сведены к минимуму, а вся бизнес-логика сосредоточена в модели. В примере с электронной коммерцией контроллер определяет последовательность веб-страниц в процессе оформления заказа и отвечает за проверку соответствия электронной почты, адреса и платёжной информации бизнес-правилам (а не передаёт эту задачу самой базе данных или коду доступа к базе данных более низкого уровня). Возможны и другие парадигмы. Например, для относительно простых бизнес-сущностей общее представление и контроллер могут обращаться к объектам базы данных, которые сами содержат всю соответствующую бизнес-логику относительно принимаемых ими форматов и возможных изменений (так называемая модель базы данных). Некоторые многоуровневые схемы используют отдельный уровень приложений или уровень обслуживания, либо считают слой бизнес-логики идентичным одному из них.

Business logic could be anywhere in a program. For example, given a certain format for an address, a database table could be created which has columns that correspond exactly to the fields specified in the business logic, and type checks added to make sure that no invalid data is added. Business logic often changes. For example, the set of allowable address formats might change when an online retailer starts shipping products to a new country. Thus it is often seen as desirable to make the code that implements the business logic relatively isolated, or loosely coupled. This makes it more likely that changes to business logic will require a small set of code changes, in only one part of the code. Distant but strongly coupled code also creates more of a risk that the programmer will only make some of the necessary changes and miss part of the system, leading to incorrect operation. A multitier architecture formalizes this decoupling by creating a business logic layer which is separate from other tiers or layers, such as the data access layer or service layer. Each layer "knows" only a minimal amount about the code in the other layers—just enough to accomplish necessary tasks. For example, in a model–view–controller paradigm, the controller and view layers might be made as small as possible, with all the business logic concentrated in the model. In the e commerce example, the controller determines the sequence of web pages in the checkout sequence, and is also responsible for validating that email, address, and payment information satisfy the business rules (rather than leaving any of that up to the database itself or lower level database access code). Alternative paradigms are possible. For example, with relatively simple business entities, a generic view and controller could access database objects which themselves contain all the relevant business logic about what formats they accept and what changes are possible (known as the database model). Some tiered schemes use either a distinct application layer or a service layer, or consider the business logic layer to be the same as one of those.

Инструменты и методы

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