В компьютерном программном обеспечении бизнес -логика или логика предметной области — это часть программы, которая кодирует реальные бизнес-правила , определяющие, как данные могут создаваться, храниться и изменяться . Оно контрастирует с остальной частью программного обеспечения, которая может быть связана с деталями более низкого уровня, связанными с управлением базой данных или отображением пользовательского интерфейса , системной инфраструктуры или общим соединением различных частей программы.
Бизнес-логика:
Бизнес правила:
Бизнес-логика включает в себя: [1]
Бизнес-логику следует отличать от бизнес-правил. [2] Бизнес-логика — это часть корпоративной системы, которая определяет, как данные преобразуются или рассчитываются и как они передаются людям или программному обеспечению (рабочий процесс). Бизнес-правила являются формальным выражением деловой политики. Все, что является процессом или процедурой, является бизнес-логикой, а все, что не является ни процессом, ни процедурой, является бизнес-правилом. Приветствие нового посетителя — это процесс (рабочий процесс), состоящий из шагов, которые необходимо предпринять, тогда как утверждение, что каждого нового посетителя следует приветствовать, является бизнес-правилом. Кроме того, бизнес-логика является процедурной, тогда как бизнес-правила являются декларативными. [3]
Например, веб-сайт электронной коммерции может позволять посетителям добавлять товары в корзину, указывать адрес доставки и предоставлять платежную информацию. Бизнес-логика веб-сайта может включать в себя такой рабочий процесс, как:
Также будут действовать правила бизнеса на сайте:
Программное обеспечение веб-сайта также содержит другой код, который не считается частью бизнес-логики или бизнес-правил:
Бизнес-логика может находиться где угодно в программе. Например, при наличии определенного формата адреса можно создать таблицу базы данных, столбцы которой точно соответствуют полям, указанным в бизнес-логике, и добавить проверки типов, чтобы убедиться, что не добавлены недопустимые данные.
Бизнес-логика часто меняется. Например, набор допустимых форматов адресов может измениться, когда интернет-магазин начнет отправлять товары в новую страну. Таким образом, часто считается желательным сделать код, реализующий бизнес-логику, относительно изолированным или слабосвязанным . Это повышает вероятность того, что изменения в бизнес-логике потребуют небольшого набора изменений кода, только в одной части кода. Удаленный, но сильно связанный код также создает больший риск того, что программист внесет только некоторые необходимые изменения и пропустит часть системы, что приведет к некорректной работе. [4]
Многоуровневая архитектура формализует это разделение, создавая уровень бизнес-логики , который отделен от других уровней или слоев, таких как уровень доступа к данным или уровень обслуживания . Каждый уровень «знает» лишь минимальную информацию о коде других уровней — ровно столько, сколько необходимо для выполнения необходимых задач. Например, в парадигме модель-представление-контроллер уровни контроллера и представления можно сделать как можно меньшими, при этом вся бизнес-логика будет сосредоточена в модели. В примере с электронной коммерцией контроллер определяет последовательность веб-страниц в последовательности оформления заказа, а также отвечает за проверку соответствия электронной почты, адреса и платежной информации бизнес-правилам (вместо того, чтобы оставлять все это на усмотрение самой базы данных). или код доступа к базе данных нижнего уровня).
Возможны альтернативные парадигмы. Например, в случае относительно простых бизнес-объектов общее представление и контроллер могут получать доступ к объектам базы данных, которые сами содержат всю соответствующую бизнес-логику о том, какие форматы они принимают и какие изменения возможны (известные как модель базы данных ).
В некоторых многоуровневых схемах используется либо отдельный уровень приложения , либо уровень обслуживания , либо уровень бизнес-логики считается таким же, как один из них.
Бизнес-логику можно извлечь из процедурного кода с помощью системы управления бизнес-правилами (BRMS). [5]
Подход к разработке программного обеспечения, основанный на бизнес -правилах, использует BRMS и обеспечивает очень строгое отделение бизнес-логики от остального кода. Системы управления пользовательским интерфейсом — это еще одна технология, используемая для обеспечения четкого разделения бизнес-логики и другого кода. Волшебная кнопка считается «анти-шаблоном»: метод, который в этом случае создает нежелательные ограничения, которые затрудняют кодирование бизнес-логики простым в обслуживании способом.
Модель предметной области — это абстрактное представление типов хранения данных, требуемых бизнес-правилами.
{{cite journal}}: Требуется журнал Cite |journal=( помощь ) — Пау и Вервест разрабатывают подход к встраиванию бизнес-логики в коммуникационную сеть, лежащую в основе распределенного приложения с множеством участников , чтобы оптимизировать распределение бизнес-ресурсов с сетевой точки зрения. .