Бизнес-логика

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

Подробности и пример

Бизнес-логика:

Описывает, как бизнес-объекты взаимодействуют друг с другом.
Обеспечивает соблюдение маршрутов и методов доступа и обновления бизнес-объектов.

Бизнес-правила:

Моделируйте реальные бизнес-объекты (такие как счета, кредиты, маршруты и запасы)

Бизнес-логика включает в себя: ^[1]

Рабочие процессы , которые представляют собой упорядоченные задачи по передаче документов или данных от одного участника (человека или программной системы) другому.

Бизнес-логику следует отличать от бизнес-правил. ^[2] Бизнес-логика — это часть корпоративной системы, которая определяет, как данные преобразуются или рассчитываются и как они передаются людям или программному обеспечению (рабочий процесс). Бизнес-правила являются формальным выражением деловой политики. Все, что является процессом или процедурой, является бизнес-логикой, а все, что не является ни процессом, ни процедурой, является бизнес-правилом. Приветствие нового посетителя — это процесс (рабочий процесс), состоящий из шагов, которые необходимо предпринять, тогда как утверждение, что каждого нового посетителя следует приветствовать, является бизнес-правилом. Кроме того, бизнес-логика является процедурной, тогда как бизнес-правила являются декларативными. ^[3]

Например, веб-сайт электронной коммерции может позволять посетителям добавлять товары в корзину, указывать адрес доставки и предоставлять платежную информацию. Бизнес-логика веб-сайта может включать в себя такой рабочий процесс, как:

Последовательность событий, происходящих во время оформления заказа, например многостраничная форма, в которой сначала запрашивается адрес доставки, затем адрес для выставления счета, следующая страница будет содержать способ оплаты, а на последней странице будут показаны поздравления.

Также будут действовать правила бизнеса на сайте:

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

Программное обеспечение веб-сайта также содержит другой код, который не считается частью бизнес-логики или бизнес-правил:

Периферийный контент, не связанный с основными бизнес-данными, например HTML-код , определяющий цвета, внешний вид, фоновое изображение и структуру навигации сайта.
Общий код обработки ошибок (например, который отображает страницу с кодом ошибки HTTP 500)
Код инициализации, который запускается при запуске веб-сервера сайта и настраивает систему.
Мониторинг инфраструктуры, чтобы убедиться, что все части сайта работают правильно (например, доступна биллинговая система).
Общий код для создания сетевых подключений, передачи объектов в базу данных , анализа пользовательского ввода через события HTTP POST и т. д.

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

Бизнес-логика может находиться где угодно в программе. Например, при наличии определенного формата адреса можно создать таблицу базы данных, столбцы которой точно соответствуют полям, указанным в бизнес-логике, и добавить проверки типов, чтобы убедиться, что не добавлены недопустимые данные.

Бизнес-логика часто меняется. Например, набор допустимых форматов адресов может измениться, когда интернет-магазин начнет отправлять товары в новую страну. Поэтому часто считается желательным сделать код, реализующий бизнес-логику, относительно изолированным или слабосвязанным . Это повышает вероятность того, что изменения в бизнес-логике потребуют небольшого набора изменений кода, только в одной части кода. Удаленный, но сильно связанный код также создает больший риск того, что программист внесет только некоторые необходимые изменения и пропустит часть системы, что приведет к некорректной работе. ^[4]

Многоуровневая архитектура формализует это разделение, создавая уровень бизнес-логики , который отделен от других уровней или слоев, таких как уровень доступа к данным или уровень обслуживания . Каждый уровень «знает» лишь минимальную информацию о коде других уровней — ровно столько, сколько необходимо для выполнения необходимых задач. Например, в парадигме модель-представление-контроллер уровни контроллера и представления можно сделать как можно меньшими, при этом вся бизнес-логика будет сосредоточена в модели. В примере с электронной коммерцией контроллер определяет последовательность веб-страниц в последовательности оформления заказа, а также отвечает за проверку соответствия электронной почты, адреса и платежной информации бизнес-правилам (вместо того, чтобы оставлять все это на усмотрение самой базы данных). или код доступа к базе данных нижнего уровня).

Возможны альтернативные парадигмы. Например, в случае относительно простых бизнес-объектов общее представление и контроллер могут получать доступ к объектам базы данных, которые сами содержат всю соответствующую бизнес-логику о том, какие форматы они принимают и какие изменения возможны (известные как модель базы данных ).

В некоторых многоуровневых схемах используется либо отдельный уровень приложения , либо уровень обслуживания , либо уровень бизнес-логики считается таким же, как один из них.

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

Бизнес-логику можно извлечь из процедурного кода с помощью системы управления бизнес-правилами (BRMS). ^[5]

Подход к разработке программного обеспечения, основанный на бизнес -правилах, использует BRMS и обеспечивает очень строгое отделение бизнес-логики от остального кода. Системы управления пользовательским интерфейсом — это еще одна технология, используемая для обеспечения четкого разделения бизнес-логики и другого кода. Волшебная кнопка считается «анти-шаблоном»: метод, который в этом случае создает нежелательные ограничения, которые затрудняют кодирование бизнес-логики простым в обслуживании способом.

Модель предметной области — это абстрактное представление типов хранения данных, требуемых бизнес-правилами.

См. также

Ссылки

^ Стивен Мински (27 марта 2005 г.). «Проблема внедрения BPM» . eBizQ.
^ «Определение бизнес-логики» . 24 декабря 2013 г.
^ Уильям Ульрих. «Симпозиум по бизнес-правилам OMG» (PDF) . Архивировано из оригинала (PDF) 24 декабря 2013 г.
^ Хавар Заман Ахмед и Кэри Э. Умрыш (17 октября 2001 г.). «Введение в корпоративное программное обеспечение». Разработка корпоративных Java-приложений с использованием J2EE и UML . Аддисон-Уэсли. ISBN 0-201-73829-5 .
^ Оуэн, Джеймс (19 сентября 2003 г.). «Раскройте бизнес-логику» . Корпоративная Java. Инфомир . Проверено 21 июля 2020 г.

Дальнейшее чтение

Бретт Маклафлин (март 2002 г.). «Бизнес-логика, часть 1» . Создание корпоративных приложений Java, Том I: Архитектура . О'Рейли и партнеры. ISBN 0-596-00123-1 . — Маклафлин обсуждает шаблон фасада для реализации бизнес-уровня приложения.
Кэти Борер (ноябрь 1997 г.). «Промежуточное ПО изолирует бизнес-логику» . Журнал «Объект» . 7 (9). Нью-Йорк, США: SIGS Publications, Inc.: 41–46. ISSN 1055-3614 .
Харуми Куно; Майк Лемон; Алан Карп и Доротея Беринджер (2001). «Разговоры + Интерфейсы = Бизнес-логика». У Ф. Казати; Д. Георгакопулос и М.-К. Шан (ред.). Технологии для электронных услуг: Второй международный семинар, TES 2001, Рим, Италия, 14–15 сентября 2001 г., Материалы . Конспекты лекций по информатике. Том. 2193. Шпрингер Берлин/Гейдельберг. ISSN 0302-9743 .
Волкер Турау (2002). «Среда для автоматического создания веб-приложений для ввода данных на основе XML» . Материалы симпозиума ACM 2002 г. по прикладным вычислениям, Мадрид, Испания: приложения для Интернета и электронного бизнеса . АКМ Пресс. стр. 1121–1126. ISBN 1-58113-445-2 . — Турау представляет платформу приложений, реализованную с использованием Java Servlets и JavaServer Pages , которая позволяет разделить бизнес-логику и логику представления, позволяя разрабатывать каждую из них параллельно по относительно независимым, но взаимодействующим направлениям.
Пау, Л.-Ф. И Вервест, PHM (8 декабря 2003 г.). «Управление бизнес-процессами на основе сети: внедрение бизнес-логики в сети связи». Серия отчетов ERIM Исследования в области менеджмента. Университет Эразма . HDL : 1765/1070 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь ) — Пау и Вервест разрабатывают подход к встраиванию бизнес-логики в коммуникационную сеть, лежащую в основе распределенного приложения с множеством субъектов , чтобы оптимизировать распределение бизнес-ресурсов с сетевой точки зрения.

Внешние ссылки

Рекомендации бизнес-уровня

[1] Стивен Мински (27 марта 2005 г.). «Проблема внедрения BPM» . eBizQ.

[2] «Определение бизнес-логики» . 24 декабря 2013 г.

[3] Уильям Ульрих. «Симпозиум по бизнес-правилам OMG» (PDF) . Архивировано из оригинала (PDF) 24 декабря 2013 г.

[4] Хавар Заман Ахмед и Кэри Э. Умрыш (17 октября 2001 г.). «Введение в корпоративное программное обеспечение». Разработка корпоративных Java-приложений с использованием J2EE и UML . Аддисон-Уэсли. ISBN 0-201-73829-5 .

[5] Оуэн, Джеймс (19 сентября 2003 г.). «Раскройте бизнес-логику» . Корпоративная Java. Инфомир . Проверено 21 июля 2020 г.

[1]

[2]

[3]

[4]

[5]