Бизнес-логика
Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «логика предметной области» (англ. domain logic ).
Проще говоря, бизнес-логика — это реализация предметной области в информационной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отправка сообщений электронной почты руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
В фазе бизнес-моделирования и разработки требований бизнес-логика может описываться в виде:
- текста;
- концептуальных аналитических моделей предметной области (онтологии);
- бизнес-правил;
- разнообразных алгоритмов;
- диаграмм деятельности;
- графов и диаграмм перехода состояний;
- моделей бизнес-процессов.
В фазе анализа и проектирования системы бизнес-логика воплощается в различных диаграммах языка UML или ему подобных. В фазе программирования бизнес-логика воплощается в коде классов и их методов, в случае использования объектно-ориентированных языков программирования, или процедур и функций, в случае применения процедурных языков.
На жаргоне разработчиков программного обеспечения «бизнес-логикой» также называются программные модули, её реализующие, и уровень системы, на котором эти модули находятся (англ. business logic layer, domain logic layer ).
В многоуровневых (многослойных) информационных системах этот уровень взаимодействует с нижележащим уровнем инфраструктурных сервисов (англ. infrastructure layer ), например, интерфейсом доступа к базе данных или файловой системе (англ. data-access layer (DAL) ) и вышележащим уровнем сервисов приложения (англ. application services layer ), который уже, в свою очередь, взаимодействует с уровнем пользовательского интерфейса (англ. user interface layer ) или внешними системами.
См. также
- Разработка программного обеспечения
- Менеджмент процессов
Wikimedia Foundation . 2010 .
Бизнес-логика, что это такое?
Шаблон MVC описывает простой способ построения структуры приложения, целью которого является отделение бизнес-логики от пользовательского интерфейса. В результате, приложение легче масштабируется, тестируется, сопровождается и конечно же реализуется.
Источник Не совсем ясно, что означает этот термин
- терминология
- шаблоны-проектирования
Отслеживать
4,651 1 1 золотой знак 14 14 серебряных знаков 51 51 бронзовый знак
задан 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. Мы его пока не трогаем.
Надо понимать, что существует огромное количество однотипных задач. Например, вывод данных в интерфейс. Для этого существуют фреймворки – набор принятых решений, я о них раньше рассказывал. Это способ автоматизации, когда программист просто подключает фреймворк, чтобы сразу нарисовался красивый интерфейс. Интерфейсы плюс-минус однотипные во всех приложениях: кнопочки, списочки, все относительно стандартно.
А вот слой бизнес-логики, где заданы правила, не может быть создан таким способом. В каждом бизнесе, даже если это пять складов, в каждом будут свои особенности. Допустим, на первом складе два помещения, и кладовщику надо знать, где именно хранится товар. А у другого склада отделения в трех городах, и надо знать, в каком городе. А у третьего склада одна каптерка, помещения ему не нужны. Зато от может отгружать товары с соседнего склада. Это простой пример, а таких правил может быть миллионы.
Например, если мы говорим о банковской сфере или телекоме, там очень сложная логика. Посмотрите как-нибудь свой договор с банком, удивитесь. Десять страниц мелким текстом. Это и есть бизнес-логика – как банк работает с вашим счетом. Персональные счета, накопительные, и так далее.
Заключение
Надеюсь, вы поняли, что такое бизнес-логика и почему это основная часть вашей работы. Потому что использование фреймворков, чтобы нарисовать кнопки на мордочке – это не программирование. Основная часть работы программиста – это передать в программе правила и логику того бизнеса, для которого вы ее пишете.
Организация бизнес-логики корпоративных приложений. Какие возможны варианты?
В этой статье мы попытаемся найти ответ на вопрос, обозначений в заголовке. А также порассуждаем на тему возможности универсального решения на все случае жизни.
Три типовых решения при работе с бизнес-логикой по Фаулеру
С одной стороны сложно писать об организации бизнес-логики в приложении. Получается очень абстрактная статья. Благо есть книги, где затронута эта тема и даже есть примеры кода. Мартин Фаулер в книге «Шаблоны корпоративных приложений» выделял три основных типовых решения. Сценарий транзакции (Transaction Script), модуль таблицы (Table Module) и модель предметной области (Domain Model). Самый элементарный из них — это сценарий транзакции. Не будем их здесь обсуждать подробно — они очень хорошо описаны в первоисточнике с примерами. Приведем для дальнейших рассуждений лишь схему все из той же книги:
На этом графике показана _приблизительная_ зависимость между сложностью доменной логики и стоимостью реализации для трех видов типовых решений. Сразу бросается в глаза очевидная схожесть между тем, как ведет себя сценарий транзакции и модуль таблицы. И совсем особняком стоит модель предметной области, которую применяют для сложной бизнес-логики. Как выбирать решение для вашего проекта? Очень просто, вы оцениваете, насколько сложная будет бизнес-логика. Например, расчет скидочной программы для клиентов. Какое типовое решение выбрать? Обычно при расчете скидок пользователи могут быть в разных категориях скидочной программы, в зависимости от категории можно получать скидки на разные группы товаров, причем товары могут входить в иерархические группы. Категории скидок распространяются на категории товаров. А еще есть число посещений заведения за заданный период. Периоды с разными характеристиками, заведения в сети заведений — различаются и т.д. и т.п. Если представить код — это приложение, в котором большое число классов с разнообразными свойствами и большое число связей между этими классами. А также разнообразные стратегии, которые оперируют всеми этими сущностями. В таком случае ответ очевиден — проектирование с использованием модели предметной области позволит вам совладать со всеми сложностями. Другой пример — у вас простое приложение, которое хранит свои данные в 3-х таблицах и никаких особенных операций с ними не делает. Рассылка сообщений по почте — список почтовых ящиков и список отправленных писем. Здесь нет смысла тащить какой-то сложный фреймворк. Простое приложение должно оставаться простым, и тут лучше выбрать модуль таблицы или даже сценарий транзакции. В зависимости от того на какой платформе вы собираетесь разрабатывать.
Сколько типовых решений на самом деле?
Похожесть двух кривых объясняется очень просто. Сценарий транзакции и модуль таблицы реализуются преимущественно с использованием процедурной парадигмы программирования. В то время как модель предметной области — с использованием объектно-ориентированной парадигмы программирования. Если посмотреть на проблему под этим углом — все становится на свои места.
Понятно, что речь не идет о чистой реализации той или иной парадигмы. Всегда есть компромиссы, вызванные ограничениями используемых технологий. Если вы пишете на C# или Java, объектно-ориентированных языках по своей природе, то это совсем не значит, что ваш код автоматически становится объектно-ориентированным. Всю программу вполне могут поместить в один единственный класс, объявить все методы статическими и использовать их из любого фрагмента кода. Таким образом, в каждом конкретном приложении будет своя кривая. Нужно лишь понять, к какой из этих двух категорий она ближе.
Как влияют фреймворки и инструменты разработки на кривую стоимости?
Сразу обозначим, что в качестве хранилища данных может выступать не только реляционная СУБД, но и NoSQL хранилище, NewSQL и даже обычные файлы, сериализованные в json, бинарный формат и т.п. Мы смотрим на ситуацию в комплексе. Если говорить про работу с обычными SQL хранилищами, здесь также огромный выбор. Вы можете писать простые запросы, писать хранимые процедуры, можете использовать ORM, использовать Code First, либо DB First подходы — все это в конечном счете сказывается на стиле, в котором написана бизнес логика. В большей степени процедурном, либо в большей степени объектно-ориентированном. Ниже я примерно обозначил свое мнение о популярных схемах работы с БД.
Проблема в том, что используемые средства накладывают ограничения, которые не позволят вам реализовать тот или иной подход в полной мере. Например, с помощью Dapper не удобно работать со сложными ассоциациями внутри доменных сущностей. А при использовании ORM уровня Entity Framework вы добавляете код для отображения сущностей на таблицы. Если говорить о NoSQL СУБД, для примера Neo4j, то там очень выразительный и мощный для своих задач язык. Но опять же это приведет к использованию процедурной парадигмы.
Насколько легко сменить выбранное решение?
Давайте попробуем представить ситуацию, где мы решили кардинально изменить схему работы с хранилищем данных. С чем мы можем в таком случае столкнуться? До этого мы обсудили два важнейших аспекта — сложность кода и стоимость его сопровождения. Но на практике этого оказывается мало. Есть еще как минимум вопрос производительности — создаваемое приложение должно быть быстрым. И это сказывается на стиле написания кода. Чем жестче требования производительности, тем более процедурный код мы получаем на выходе. В каком-то экстремальном случае это может быть сервис или приложение, написанное с использованием полностью SQL, где вся логика скрыта в хитрообразных джойнах, оконных функция и обобщенных табличных выражениях. Работает быстро, но перевести его на ORM уже не так просто — все равно, что переписать с нуля. Развитие такого продукта также может столкнуться с сложностями, учитывая график выше и процедурный стиль. Еще один вопрос — консистентность данных. Например, реляционные СУБД предоставляют очень богатые возможности по работе с транзакциями. Разобравшись с ними один раз — можно легко писать код, где вы точно знаете, какие данные увидит пользователь, какие сможет изменить. С другой стороны, если вы пользуетесь ORM и выносите всю вашу бизнес-логику в классы, работать в терминах транзакций становится сложнее. Обычно происходит реорганизация структуры таблиц и даже бизнес-сценариев таким образом, что они начинают работать в стиле согласованности данных в конечном счете (eventual consistency). Очевидно, что это также затрудняет перевод с одной схемы на другую, если вы заранее не заложили такую возможность. Компетенцию команды также не следует сбрасывать со счетов. Часто разработчики знают хорошо либо SQL, либо ORM, и при переходе можно неожиданно столкнуться с проблемами.
Выводы
Из всего, что мы обсудили, можно сделать выводы:
- При проектировании сервиса с нуля лучше сразу прогнозировать дальнейшее развитие этого сервиса и выбирать наиболее подходящее типовое решение.
- Если дальнейшее развитие для сервиса не очевидно, то лучше сразу позаботиться о возможной смене парадигмы. Например, предпочитая eventual consistency. При добавлении нового функционала всегда держать в уме возможность смены решения.
- Для доставшегося в «наследство» программного кода одно из первых действий — это оценка степени соответствия выбранного типового решения и объема уже реализованной логики. Как показывает практика — это наиболее частая причина технического долга.
Какие еще выводы вы могли бы предложить? Оставляйте ваши комментарии, давайте обсудим.