На компьютере программное обеспечение, бизнес-логика или доменная логика — это часть программы, которая кодирует реальные бизнес-правила, которые определяют, как данные могут быть созданы, сохранены и изменены. Это контрастирует с остальной частью программного обеспечения, которая может быть связана с деталями более низкого уровня управления базой данных или отображением пользовательского интерфейса, системной инфраструктуры или в целом соединения различных частей программа.
Бизнес-логику следует отличать от бизнес-правил. Бизнес-логика — это часть корпоративной системы, которая определяет, как данные преобразуются или рассчитываются и как они направляются людям или программному обеспечению (рабочий процесс). Бизнес-правила — это формальные выражения бизнес-политики.
Все, что является процессом или процедурой, является бизнес-логикой, а все, что не является ни процессом, ни процедурой, является бизнес-правилом. Приветствие нового посетителя — это процесс (рабочий процесс), состоящий из шагов, которые необходимо предпринять, а утверждение, что каждого нового посетителя нужно приветствовать, — это бизнес-правило. Кроме того, бизнес-логика носит процедурный характер, тогда как бизнес-правила декларативны.
Что такое бизнес-логика? (на примере Django)
Например, веб-сайт электронной коммерции может позволить посетителям добавлять товары в корзину, указывать адрес доставки и поставлять Платежная информация. Бизнес-логика веб-сайта может включать такой рабочий процесс, как:
- Последовательность событий, которые происходят во время оформления заказа, например, многостраничная форма, которая сначала запрашивает адрес доставки, а затем адрес выставления счетов, следующая страница будет содержать способ оплаты, и на последней странице будут показаны поздравления.
Также будут действовать бизнес-правила веб-сайта:
- Добавление товара более одного раза со страницы описания товара увеличивает количество этого товара.
- Конкретные форматы, которым должны соответствовать адрес посетителя, адрес электронной почты и информация о кредитной карте.
- Особый протокол связи для связи с сетью кредитной карты
Программное обеспечение веб-сайта также содержит другой код, который не рассматривается часть бизнес-логики или бизнес-правил:
- Периферийный контент, не связанный с основными бизнес-данными, например HTML, который определяет цвета, внешний вид, фоновое изображение и структуру навигации сайта
- Общий код обработки ошибок (например, который отображает страницу с кодом ошибки HTTP 500)
- Код инициализации, который запускается, когда веб-сервер запускает сайт, который настраивает систему
- Инфраструктура мониторинга, чтобы убедиться, что все части сайта работают правильно (например, доступна биллинговая система)
- Общий код для установления сетевых подключений, передачи объектов в базу данных, синтаксического анализа пользовательского ввода с помощью событий HTTP POST и т. д.
Бизнес-логика и уровни / уровни
Теоретически бизнес-логика занимает средний уровень трехуровневой архитектуры.
Что такое бизнес-логика и как ее изолировать
Бизнес-логика может быть где угодно в программе. Например, учитывая определенный формат адреса, можно создать таблицу базы данных, в которой будут столбцы, которые точно соответствуют полям, указанным в бизнес-логике, и добавлены проверки типов, чтобы убедиться, что не добавлены недопустимые данные.
Бизнес-логика часто меняется. Например, набор допустимых форматов адресов может измениться, когда интернет-магазин отправляет товары в новую страну. Таким образом, часто считается желательным сделать код, реализующий бизнес-логику, относительно изолированным или слабо связанным. Это повышает вероятность того, что для изменения бизнес-логики потребуется небольшой набор изменений кода, только в одной части кода. Отдаленный, но сильно связанный код также создает больший риск того, что программист внесет только некоторые необходимые изменения и пропустит часть системы, что приведет к некорректной работе.
A многоуровневая архитектура формализует это разделение, создавая уровень бизнес-логики, который отделен от других уровней или уровней, таких как уровень доступа к данным или уровень обслуживания. Каждый уровень «знает» только минимальную информацию о коде на других уровнях — ровно столько, чтобы выполнить необходимые задачи. Например, в парадигме модель – представление – контроллер уровни контроллера и представления можно было бы сделать как можно меньшими, при этом вся бизнес-логика сосредоточена в модели. В примере электронной коммерции контроллер определяет последовательность веб-страниц в последовательности оформления заказа, а также отвечает за проверку соответствия электронной почты, адреса и информации о платеже бизнес-правилам (вместо того, чтобы оставлять это на усмотрение самой базы данных. или код доступа к базе данных нижнего уровня).
Возможны альтернативные парадигмы. Например, с относительно простыми бизнес-объектами общее представление и контроллер могут получить доступ к объектам базы данных, которые сами содержат всю соответствующую бизнес-логику о том, какие форматы они принимают и какие изменения возможны (известная как модель базы данных ).
Некоторые многоуровневые схемы используют либо отдельный уровень приложения, либо уровень обслуживания, либо считают уровень бизнес-логики таким же, как один из них.
Инструменты и методы
Бизнес-логика может быть извлечена из процедурного кода с помощью системы управления бизнес-правилами (BRMS).
Бизнес Подход с использованием правил разработки программного обеспечения использует BRMS и обеспечивает очень строгое отделение бизнес-логики от остального кода. Системы управления пользовательским интерфейсом — еще одна технология, используемая для обеспечения четкого разделения бизнес-логики и другого кода. Магическая кнопка считается «анти-шаблоном»: метод, который в этом случае создает нежелательные ограничения, которые затрудняют кодирование бизнес-логики простым в обслуживании способом.
A модель предметной области — это абстрактное представление типов хранения данных, требуемых бизнес-правилами.
См. Также
- Drakon-chart
- Логика перемещения
Ссылки
Дополнительная литература
- Бретт Маклафлин (март 2002 г.). «Бизнес-логика, часть 1». Создание корпоративных приложений Java, Том I: Архитектура. O’Reilly and Associates. ISBN 0-596-00123-1.- Маклафлин обсуждает шаблон фасада для реализации бизнес-уровня приложения.
- Кэти Борер (ноябрь 1997 г.). «Промежуточное ПО изолирует бизнес-логику». Журнал «Объект». Нью-Йорк, США: SIGS Publications, Inc. 7 (9): 41–46. ISSN1055-3614.
- Харуми Куно; Майк Лемон; Алан Карп и Доротея Берингер (2001). «Разговоры + Интерфейсы = Бизнес-логика». В Ф. Касати; Д. Георгакопулос и М.-К. Шан (ред.). Технологии для электронных услуг: Второй международный семинар, TES 2001, Рим, Италия, 14–15 сентября 2001 г., Материалы. Конспект лекций по информатике. 2193 . Springer Berlin / Heidelberg. ISSN0302-9743.
- Фолькер Турау (2002). «Фреймворк для автоматического создания веб-приложений для ввода данных на основе XML». Материалы симпозиума ACM 2002 г. по прикладным вычислениям, Мадрид, Испания: веб-приложения и приложения для электронного бизнеса. ACM Press. С. 1121–1126. ISBN 1-58113-445-2.- Turau представляет структуру приложения, реализованную с использованием Java Servlets и JavaServer Pages, что позволяет разделить бизнес-логика и логика представления, позволяющие развиваться параллельно по относительно независимым, но взаимодействующим направлениям.
- Pau, LF. И Vervest, P.H.M. (2003-12-08). «Сетевое управление бизнес-процессами: внедрение бизнес-логики в сети связи». ERIM Report Series Research in Management. Университет Эразма. hdl : 1765/1070. Цитировать журнал требует | journal = () — Разработка Pau и Vervest подход для встраивания бизнес-логики в сеть связи, лежащую в основе распределенного приложения с множеством участников, для оптимизации распределения бизнес-ресурсов с точки зрения сети.
Внешние ссылки
Источник: alphapedia.ru
Бизнес-логика
Бизнес-логика — это настраиваемые правила или алгоритмы,. которые обрабатывают обмен информацией между базой данных и пользовательским интерфейсом. Бизнес-логика — это, по сути, часть компьютерной программы, которая содержит информацию (в форме бизнес-правил), которая определяет или ограничивает то, как работает бизнес. Такие бизнес-правила представляют собой операционные политики, которые обычно выражаются в истинных или ложных двоичных файлах. Бизнес-логику можно увидеть в рабочих процессах, которые они поддерживают, например, в последовательностях или шагах, которые подробно определяют надлежащий поток информации или данных и, следовательно, принятие решений. Бизнес-логика также известна как «логика предметной области».
Понимание бизнес-логики
Иными словами, бизнес-логика — это реальные бизнес-правила, заложенные в компьютерный код и отображаемые в компьютерной программе через пользовательский интерфейс. Бизнес-логика наиболее очевидна в своей роли в создании рабочих процессов, которые передают данные между пользователями и программными системами.
Бизнес-логика определяет, как данные могут отображаться, храниться, создаваться и изменяться. Он предоставляет систему правил, которая определяет, как бизнес-объекты (части программного обеспечения, управляющие транспортировкой данных) взаимодействуют друг с другом. Бизнес-логика также определяет, как осуществляется доступ к бизнес-объектам в программном обеспечении и как они обновляются. Он существует на более высоком уровне, чем тип кода, который используется для поддержки базовой компьютерной инфраструктуры, например, как база данных отображается для пользователя или как базовая системная инфраструктура.
Алгоритмы, задействованные в бизнес-логике, выполняют скрытую обработку данных, которая невидима для пользователя, но имеет решающее значение для обеспечения бесперебойной работы в современной экономике.
Бизнес-логика и бизнес-правила
Бизнес-правила бесполезны без бизнес-логики, определяющей, как данные рассчитываются, изменяются и передаются пользователям и программному обеспечению. Но без бизнес-правил для создания структуры бизнес-логика не может существовать. Бизнес-логика — это любая часть бизнес-предприятия, которая составляет систему процессов и процедур, тогда как все остальное является примером бизнес-правила.
Пример бизнес-логики
Бизнес-логика эмитента кредитной карты может указывать, что транзакции по кредитным картам за пределами штата, превышающие определенный предел, скажем, 500 долларов США, помечаются как подозрительные, и с эмитентом связываются как можно скорее для подтверждения подлинности транзакции. Политика пометки такой транзакции является примером бизнес-правила; фактический процесс пометки транзакции является примером бизнес-логики. Учитывая, что миллионы транзакций по кредитным картам проводятся каждый день, бизнес-логика позволяет проверять и обрабатывать такие транзакции эффективно и своевременно.
Особенности
- Бизнес-логика существует на более высоком уровне, чем тип кода, который используется для поддержки базовой компьютерной инфраструктуры.
- Бизнес-логику можно увидеть в рабочих процессах, которые они поддерживают, например, в последовательностях или шагах, которые подробно определяют надлежащий поток информации или данных
- Бизнес-логика относится к логике и алгоритмам, служащим основой кода в бизнес-программном обеспечении.
Бизнес логика в хранимках — это хорошо или плохо?
Существует расхожее мнение, что бизнес-логика в хранимках — это зло. Однако от опытных разработчиков нередко можно услышать, что это не так. Давайте разбираться.
- Первый подход — это использование хранимых процедур.
- Альтернативный подход — это объектно-реляционное отображение.
Есть две хороших статьи, описывающих проблематику: раз (оригинал) и два.
Первая описывает проблематику и хорошо показывает отличия систем с одним, двумя, тремя и N звеньями. В ней автор убедительно доказывает, что вся бизнес-логика должна быть в бизнес слое. Вместе с тем, автор также сообщает, что:
Нормальный язык разработки может быть использован для реализации бизнес правил. Такие языки более гибкие и более подходят для бизнес правил, чем SQL и хранимые процедуры.
По сути этим же утверждением автор приходит к мысли, что:
База данных не должна иметь функционального знания о том, что же из себя представляет покупатель в бизнес слое.
В комментариях к статье можно встретить и такое утверждение, вполне созвучное с утверждениями автора статьи:
Вообще SQL как язык удобен только для консоли, в программировании он не нужен.
На каком-то форуме встречал и такое эмоциональное высказывание (к сожалению не могу найти, чтобы добавить ссылку):
Только полный дурак будет хранить бизнес-логику в хранимках
Есть другое мнение. Автор второй статьи сообщает:
Я видел много разных ORM, но не видел ни одного хорошего. То есть такого, который за пределами простых примеров не превращается в обузу и прокрустово ложе
…
Я искренне извиняюсь перед теми братьями по профессии, кто вложил массу времени и усилий в создание многочисленных универсальных лучших в мире ORM. Мне правда очень жаль.
В его статье перечислены приёмы, позволяющие успешно применять первый подход.
