Бизнес-логика (Business logic)
Бизнес-логика — это система бизнес-правил, описывающих поведение объектов и процессов предметной области, а также представляющая эти процессы в информационных системах. Бизнес-логика определяет методы и алгоритмы анализа данных, а также способы передачи его результатов пользователям.
Примером бизнес-логики является процесс «встречи» клиента, посетившего сайт компании. Она включает запрос имени и пароля, вывод приветственной надписи, отображение персональных предложений (если есть), вывод поздравления, если посещение происходит в праздник или день рождения клиента, вывод предложения добавить товары в корзину и информации о методах оплаты. В то же время высказывание о необходимости «встречи» клиента является бизнес-правилом.
Можно сказать, что все, что является процессом, процедурой — можно отнеси к бизнес-логике. Напротив, все, что процессом и процедурой не является — является бизнес-правилами. Таким образом, бизнес-логика носит процедурный характер, а бизнес-правила — декларативный.
В области разработки программного обеспечения бизнес-логикой также называются реализующие ее программные модули и уровни системы, на которых эти модули расположены.
Бизнес-логика, что это такое?
Шаблон MVC описывает простой способ построения структуры приложения, целью которого является отделение бизнес-логики от пользовательского интерфейса. В результате, приложение легче масштабируется, тестируется, сопровождается и конечно же реализуется.
Источник Не совсем ясно, что означает этот термин
- терминология
- шаблоны-проектирования
Отслеживать
4,651 1 1 золотой знак 14 14 серебряных знаков 50 50 бронзовых знаков
задан 24 июл 2016 в 16:26
user33274 user33274
5 ответов 5
Сортировка: Сброс на вариант по умолчанию
Бизнес-логика — это логика доменной модели — все, что в вашем приложении происходит в терминах предметной области.
Например, на SO — это все действия с пользователями, вопросами, ответами, плюсы, минусы и т.д.
- Если пользователь не набрал ZZZ репутации — отправить его правку на проверку другими участниками — это бизнес-логика, ей место в модели.
- Перенаправить пользователя на страницу вопроса после его создания — не-бизнес логика, которой место в контроллере.
- Скрыть кнопку «Оставить комментарий» если текущий пользователь не имеет право оставлять комментарии — особенности представление данных (флага из модели) — во view.
MVC позволяет выделить «не-бизнес» логику, связанную с пользовательским интерфейсом:
- вызовы методов модели по определенным действиям пользователя
- отображение/скрытие контролов
- подготовку данных к отправке на клиента.
. и поместить логику представления в отдельный кусок приложения — Controller.
тем самым оставив в модели «чистую» бизнес-логику, не привязанную к интерфейсу пользователя.
Стоит отметить, что ссылка в вопросе ведет на статью, иллюстрированную диаграммой Classic MVC. Реально в Web используется более современный вариант паттерна — MVC Model2 — и его производные. Его отличие — View не взаимодействует с моделью напрямую.
Взаимодействие в современном MVC выглядит вот так:
Отслеживать
ответ дан 25 июл 2016 в 8:09
user177221 user177221
Оборот про «И поместить ее в отдельный кусок приложения — Controller.» совсем не понятен. А еще не понятно как бизнес-логика связана с контролером
25 июл 2016 в 11:11
Я к тому, что процитированный мной кусок, по-логике содержит опечатку. Вместо Controller должно быть Model. Или я чего-то не понимаю?
25 июл 2016 в 11:33
@DmitriySimushev о, там предложения местами поменялись. исправил, спасибо.
– user177221
25 июл 2016 в 11:37
@PavelMayorov ну да, «предметная область и ее логика» и «код, реализующий логику предметной области» — это две разные вещи. Но обычно под BL подразумевают именно часть приложения, в которой логика предметной области изложена в виде кода. А не просто какие-то абстрактные правила, которые существуют в голове у экспертов в предметной области.
– user177221
25 июл 2016 в 12:09
@DuosDuo очень легко проверить. Представьте, что у вас есть полностью другой ui, например, мобильное приложение. Если в нем поведение будет другое — то это не бизнес логика. Показать сообщение — не бизнес логика. Проверить активацию учётки, залогировать для аудита попытку доступа — бизнес логика.
– user177221
28 окт 2019 в 14:51
Бизнес-логика — то же самое что и логика предметной/доменной/прикладной области. Допустим, вы программируете софт для приюта животных и для детского приюта.
По бизнес-логике приюта для животных, предположим, котика, которого за неделю не забрали новые хозяева, надо усыпить. А до этого его надо кормить, поить и спать укладывать.
По бизнес-логике детского приюта — ребенка надо кормить, поить и спать укладывать. В него нельзя втыкать шприц со смертельной дозой морфия.
При этом все структуры данных, алгоритмы и т.д. — в двух программах практически одинаковы. Кроме вот этой маленькой детали.
«ЭТОТ один ИФЧИК решил СУДЬБУ КОТЕЙКИ», или, например «начинающий программист УБИЛ младенца ВЕКТОРОМ»
Если вы перепутаете бизнес-логику приюта для животных и детского приюта, и усыпите ребенка, а котенку подарите куклу, вы, надеюсь, попадете в тюрячку, там вам все за ООП расскажут.
Не важно, бизнес это, расчет конфигурации молекул, приют или управление кораблем. Бизнес-логика — это та самая часть, которая в итоге должна работать правильно и надежно, та, результатов которой ждет заказчик (котенок, ребенок)
Если не отделять, допустим интерфейс от бизнес-логики, то вместо нажатия кнопки «отдать ребенка новым родителям» или «усыпить котенка», на двух аккуратных — почти похожих — пультах управления (интерфейсах) вы будете бегать туда-сюда, пытаясь понять, кого утопить, кого усыпить, кого отдать новым родителям и почему ничего не работает.
Вы не отделили интерфейс (панель управления для запуска котят на луну) от бизнес-логики и все запуталось.
Ну, я предупреждал.
Используете вы синглтоны, очереди, базы данных, флэт-файлы, микросервисы — не важно — важно, чтобы бизнес-логика работала правильно.
Под правильно подразумевается корректность результатов в приемлемое время. Все остальное ваших заказчиков не интересует. До тех пор, пока они не являются вашими владельцами.
Именно поэтому вы можете продавать очень плохой — с точки зрения программиста — софт клиентам, но с трудом сможете построить на нем надежную систему. Требования бизнес-логики может быть и выполняются, но поддерживать этот код невозможно
P.S. Маленький исторический экскурс. Бизнес-логикой это называется потому, что в Нормальном Мире, во Внешней Империи, программирование в коммерции и корпорациях развивалось еще с 50х-60х годов: банки, страховые агентства, туроператоры, медицина.
Т.е. тебе платили за то, чтобы ты внедрил требования конкретного бизнеса
Хорошо, что это бизнес-логика, а не партийная логика, как в Северной Корее.
Что такое “бизнес логика”? И как начать ее понимать
Для чего нужна программа? Большинство новичков-программистов говорят: я буду писать программы. Программа – это что-то кому-то нужное. Ее кто-то будет использовать, чтобы достигать свои цели.
Если это бизнес-программа – в ней будут обрабатываться бизнес-данные. Это может быть бухгалтерская программа, складская, программа управления персоналом, логистикой, телекомом, — неважно, но она должна делать что-то полезное для бизнеса. Например, учитывать товары, которые приходят на склад
Простой пример
На склад приходит товар. Кладовщик-приемщик должен взять и вбить в программу товары, которые пришли, и сколько. Потому что склад большой. И когда к нему придут и спросят – а есть у тебя пять ведер? Он должен открыть программу и посмотреть – да, пять ведер есть. И если спросят, то проверить, по какой накладной и от какого поставщика они пришли.
Вроде бы просто. Но если бы не было программы, ему бы пришлось все это записывать на бумажках. И если склад большой, то разбираться в этих бумажках можно год. Или два. И не разобраться. Поэтому программа нужна, и такие программы пишутся в интересах пользователей.
Бизнес-логика
Если мы говорим про бизнес, для которого и пишутся 95% программ, то логика программы – то, что она делает – это и есть бизнес-логика. По-английски — domain. Это правила, которые содержатся в самом бизнесе. Например, не может существовать накладная без единой позиции – это значит, что ничего не пришло, и накладной просто нет. Или нельзя отправить со склада товар, которого на складе нет и не было. Самые простые требования, которые вам придут в голову первыми. Но в любом бизнесе таких правил – тысячи.
Ваша программа фактически будет содержать эти правила, и следить за тем, чтобы правила соблюдались пользователями. В случае со складом это кладовщик.
Слои в приложениях
У любого приложения есть три слоя. Слой пользовательского интерфейса – это вывод данных, кнопочки, списки, стрелочки, и другие элементы, которые показываются пользователю. Слой бизнес-логики – тот самый, где прописаны бизнес-правила по требованию заказчика. И слой сохранения данных, он же consistency. Мы его пока не трогаем.
Надо понимать, что существует огромное количество однотипных задач. Например, вывод данных в интерфейс. Для этого существуют фреймворки – набор принятых решений, я о них раньше рассказывал. Это способ автоматизации, когда программист просто подключает фреймворк, чтобы сразу нарисовался красивый интерфейс. Интерфейсы плюс-минус однотипные во всех приложениях: кнопочки, списочки, все относительно стандартно.
А вот слой бизнес-логики, где заданы правила, не может быть создан таким способом. В каждом бизнесе, даже если это пять складов, в каждом будут свои особенности. Допустим, на первом складе два помещения, и кладовщику надо знать, где именно хранится товар. А у другого склада отделения в трех городах, и надо знать, в каком городе. А у третьего склада одна каптерка, помещения ему не нужны. Зато от может отгружать товары с соседнего склада. Это простой пример, а таких правил может быть миллионы.
Например, если мы говорим о банковской сфере или телекоме, там очень сложная логика. Посмотрите как-нибудь свой договор с банком, удивитесь. Десять страниц мелким текстом. Это и есть бизнес-логика – как банк работает с вашим счетом. Персональные счета, накопительные, и так далее.
Заключение
Надеюсь, вы поняли, что такое бизнес-логика и почему это основная часть вашей работы. Потому что использование фреймворков, чтобы нарисовать кнопки на мордочке – это не программирование. Основная часть работы программиста – это передать в программе правила и логику того бизнеса, для которого вы ее пишете.
Что такое бизнес-логика
Бизнес-логика – это набор правил (условий), которым подчиняются объекты, сущности, классы и данные внутри программы. Просто посмотрите на обложку этой статьи, на ней изображен пример простой бизнес-логики.
Не стоит бояться бизнес-логики
Многие программисты пугаются и боятся данного термина как огня, хотя он несет в себе элементарный смысл. Можно упростить термин до одного понятного предложения: логика, присущая какому-то конкретному бизнесу или определенному участку программы.
В любом приложении есть какая-то логика, присущая только ему. Данный код невозможно перенести в другую программу (другой бизнес) как библиотеку или фреймворк. Бизнес-логика может быть как относительно простой – пару условий, так и очень сложной, где не обойтись без цепочки условий или даже машинного обучения.
Интерфейс отдельно, бизнес-логика отдельно
В современных приложениях принято отделять бизнес-логику от остальных участков программы. Для примера давайте рассмотрим популярный паттерн проектирования MVC.
MVC – (с анг. Model, View, Controller) это схема разделения данных в приложении на три компонента: модель, представление, контроллер.
MVC приложение состоит из 3 частей. Controller – обрабатывает все запросы с браузера, которые генерирует пользовать (например, запрашивает открытие какой-то страницы). Когда пользователь вызвал Controller, тот в свою очередь вызывает какой-то участок кода из Model. А это уже наш слой с бизнес-логикой, он связывается с базой данных и как-то обрабатывает данные. Когда Model выполнила код, то результат (объект с преобразованными данными) возвращается в Controller, и тот вызывает View, запихивая в него данные и отдавая пользователю (уже готовую веб-страницу).
Как видите, это позволяет разделять приложение на разные слои и в последствии позволяет гораздо проще его обслуживать. Вообще, существует множество паттернов проектирования, и все они призваны разделять данные между собой (чтоб каши не было в одном файле). MVC тоже не идеальный пример архитектуры, и когда данных становится очень много, то люди придумывают новые схемы разделения (MVP, MVVM, Monkey Patching и еще куча разных схем).
Итог
Когда в следующий раз увидите определение “бизнес-логика”, читайте просто как “логика”.