Бизнес логика это что
Бизнес-логика в no-code: что это и как ее построить
Бизнес-логика приложения – это, по сути, описание схем, по которым приложение взаимодействует с пользователем. Когда пользователь оформляет подписку, или заполняет форму заказа, или просто авторизуется – все эти действия обрабатываются «под капотом» приложения в определенном порядке.
Какие данные нужно запросить? Соответствуют ли введенные данные заданному формату? Что произойдет после того, как пользователь нажмет кнопку «Подтвердить»? А есть ли вообще у него права доступа к данной операции? На все эти и многие другие вопросы можно ответить, изучив, как построена бизнес-логика конкретного приложения.
Простейший пример: администратор авиакомпании (пользователь) регистрирует пассажира на рейс (вносит информацию в базу данных).
1.Открывает информацию о выбранном рейсе, переходит к списку уже зарегистрированных пассажиров, нажимает «Зарегистрировать пассажира».
2.Заполняет форму регистрации: вводит номер рейса, выбирает пассажира, указывает место и статус регистрации.
3.Нажимает кнопку «Подтвердить»
4.Видит нового пассажира в общем списке.
1.Приложение проверяет, авторизован ли пользователь и имеет ли права доступа к выбранной странице, а также операции регистрации.
2.Ждет, пока пользователь заполнит форму.
3.Обрабатывает введенные данные:
a. Проверяет, соответствуют ли введенные данные требованиям приложения (эти требования заранее прописаны программистом): например, в поле «Номер рейса» должно быть целое число.
b. Получает из базы данных информацию: например, о рейсе и связанных с ним регистрациях (чтобы внести изменения), пассажире (чтобы проверить, действительно ли этот пассажир есть в базе данных).
c. Выдает сообщения об ошибках, если поля заполнены неверно.
d. Отправляет информацию в базу данных, отдавая команды на создание в ней новых записей или обновлении существующих.
4.Выводит обновленную информацию на экран.
Общая логика приложения строится из бизнес-процессов – схем, описывающих конкретные операции в системе: создание записи о пассажире, добавление в систему нового рейса, редактирование информации о регистрации.
Когда речь идет о классическом программировании, то для описания всех процессов используются блоки кода. Многие из них пишутся по шаблонам – просто используются в разной последовательности и для работы с разными данными.
Именно благодаря этой «шаблонности» в no-code разработке появилась возможность использовать инструменты визуального программирования – так называемые дизайнеры бизнес-логики. Они помогают выбрать нужные блоки, скомпоновать в нужной последовательности, настроить. И даже создать некоторые блоки автоматически, в зависимости от настроек других компонентов приложения. Итог – готовая бизнес-логика без необходимости проводить многие часы над строками кода.
Что такое бизнес логика android приложения?
Простой 1 комментарий
Бизнес-логика, это правила того или иного бизнеса. Бизнес-модель, это модель которая описывает бизнес-процессы организации/компании/сообщества и т.п.
Например это может быть логика расчета «премии» сотрудникам. Это может быть логика например вычисления пенни за просроченный платеж. Или например в компании существуют критерии и правила по которым устанавливается лучший сотрудник месяца. А может быть у вас есть компания которая занимается логистикой и есть определенные правила по которым в компании вычисляют маршрут доставки и виды транспорта которым груз будет доставляться. Описание этих критериев и правил в программном коде и есть бизнес-логика.
Как правило бизнес-логика не меняется от приложения к приложению и не зависит от платформ и фреймворков вообще. Она меняется когда меняется сам бизнес, структура организации, взаимодействия внутри компании бизнес которой вы автоматизируете с помощью приложения.
Бизнес логика не от слова «бизнес как средство получения прибыли», а от слова бизнес как «выполняемое дело»,
«Как бы бред написали». Процитируйте, где я сказал что это логика бизнеса как средства получения прибыли? Я сказал что бизнес-логика это средство описания бизнес-процессов. Бизнес-процесс — это совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого продукта или услуги для потребителей. ( Читать: https://en.wikipedia.org/wiki/Business_logic )
Вынесение б.л. в отдельные от слоя данных объекты красивая, но не всегда применимая концепция, хотя в целом хорошо укладывается в практически все принципы ООП (читать AR vs DataMapper)
`AR и DataMapper` это детали реализации инфраструктурного слоя и не более. А концепция отделения БЛ в отдельный слой применима даже за рамками контекста ООП. Хотя есть случай когда она не применима. Это когда вы пишете на PHP-шном FullStack фреймворке и женились на нем. (Читать: Мартина Фаулера)
построение связей между программными компонентами.
Бизнес-логика — это то, что программа делает с точки зрения пользователя. По-другому (и более понятно) — логика предметной отрасли.
Например, у нас есть игра в шахматы. Бизнес-логика — это правила шахмат, принципы работы часов, команды «попросить ход назад», «сдаться» и «согласиться на ничью». Если нужно начинать не с исходной позиции, а с любой — то редактор.
Крайне спорно, относить ли к бизнес-логике — анимация фигурок на манер Battle Chess и боты.
Логика, которая не бизнес — это работа с сетью, графикой, конфигурационными файлами, сохранениями досок и партий, античит и многое другое. В общем, то, что нужно для жизнеобеспечения программы, а не для предметной отрасли. Сохранять партии в PGN или XML, как перекидываться пакетами по сети и какие настройки держать для совместимости…
Предположим, вы хотите написать программу, которая будет считать коммунальные расходы.
Бизнес-логика, что это такое?
Шаблон MVC описывает простой способ построения структуры приложения, целью которого является отделение бизнес-логики от пользовательского интерфейса. В результате, приложение легче масштабируется, тестируется, сопровождается и конечно же реализуется.
Не совсем ясно, что означает этот термин
5 ответов 5
MVC позволяет выделить «не-бизнес» логику, связанную с пользовательским интерфейсом:
тем самым оставив в модели «чистую» бизнес-логику, не привязанную к интерфейсу пользователя.
Взаимодействие в современном MVC выглядит вот так:
По бизнес-логике приюта для животных, предположим, котика, которого за неделю не забрали новые хозяева, надо усыпить. А до этого его надо кормить, поить и спать укладывать.
Если вы перепутаете бизнес-логику приюта для животных и детского приюта, и усыпите ребенка, а котенку подарите куклу, вы, надеюсь, попадете в тюрячку, там вам все за ООП расскажут.
Вы не отделили интерфейс (панель управления для запуска котят на луну) от бизнес-логики и все запуталось.
Под правильно подразумевается корректность результатов в приемлемое время. Все остальное ваших заказчиков не интересует. До тех пор, пока они не являются вашими владельцами.
P.S. Маленький исторический экскурс. Бизнес-логикой это называется потому, что в Нормальном Мире, во Внешней Империи, программирование в коммерции и корпорациях развивалось еще с 50х-60х годов: банки, страховые агентства, туроператоры, медицина.
Т.е. тебе платили за то, чтобы ты внедрил требования конкретного бизнеса
Хорошо, что это бизнес-логика, а не партийная логика, как в Северной Корее.
Что такое бизнес-логика
Логика, да не совсем та
Дорогие читатели, в 100% случаев вы используете логику для того, чтобы разобраться в том, как работает продукт, который вы делаете и вам кажется, что именно это и есть UX. Основную часть того самого UX составляет бизнес-логика. Скорее всего вы спросите, почему дизайнера вообще должен волновать вопрос бизнеса. Ну логика-то ладно, а что такое бизнес-логика?
Давайте разберемся, что же такое бизнес-логика:
Бизнес-логика описывает работу всех бизнес-процессов, существующих в продукте.
Воу-воу-воу, полегче.. Это же и есть UX!
И да и нет. Под термином «Бизнес-логика» действительно понимают UX, но есть существенный нюанс.
Обычно к UX-дизайну относятся только пользовательские сценарии. Тогда как бизнес-логика описывает именно бизнес-процессы, происходящие под капотом UX с сугубо технической точки зрения.
Если бизнес-логика отвечает на вопрос:
«Как продукт должен работать технически?»
То UX-дизайн отвечает на вопрос:
«Как пользователь будет пользоваться продуктом и как сделать этот процесс максимально удобным и быстрым?».
Наглядная разница
UX-дизайн рассматривает ситуации (сценарии), с которыми сталкивается пользователь в процессе использования продукта; проблемы, которые продукт должен решить, чтобы им было интересно, выгодно или, как минимум, удобно пользоваться.
Бизнес-логика, наоборот, есть набор различных бизнес-процессов, возникающих внутри продукта. Они связаны между собой сугубо технически и никак не связаны с UX-дизайном.
UX-дизайн
То, как видит логику работы части приложения UX-дизайнер.
Бизнес-логика
То, что должен видеть хороший UX-дизайнер и продакт менеджер.
В реальной жизни бизнес-процесс устроен несколько сложнее, но общая идея и различие с UX-дизайном должны быть понятно.
Тэйк эвэй
Термин «Бизнес-логика» вы вряд ли услышите в стартапе, нацеленном на продажу смуззи, зато этот термин в широком ходу в B2B и интеграторах.
Теперь вас точно не испугаешь замысловатым вопросом «А как устроена бизнес-логика?». Помните, что бизнес-логика – это про весь механизм работы продукта, а UX-дизайном является лишь то, что по факту увидит пользователь в интерфейсе, в email и sms, отправленные вашим продуктом.
Организация бизнес-логики корпоративных приложений. Какие возможны варианты?
В этой статье мы попытаемся найти ответ на вопрос, обозначений в заголовке. А также порассуждаем на тему возможности универсального решения на все случае жизни.
Три типовых решения при работе с бизнес-логикой по Фаулеру
Сколько типовых решений на самом деле?
Понятно, что речь не идет о чистой реализации той или иной парадигмы. Всегда есть компромиссы, вызванные ограничениями используемых технологий. Если вы пишете на C# или Java, объектно-ориентированных языках по своей природе, то это совсем не значит, что ваш код автоматически становится объектно-ориентированным. Всю программу вполне могут поместить в один единственный класс, объявить все методы статическими и использовать их из любого фрагмента кода. Таким образом, в каждом конкретном приложении будет своя кривая. Нужно лишь понять, к какой из этих двух категорий она ближе.
Как влияют фреймворки и инструменты разработки на кривую стоимости?
Проблема в том, что используемые средства накладывают ограничения, которые не позволят вам реализовать тот или иной подход в полной мере. Например, с помощью Dapper не удобно работать со сложными ассоциациями внутри доменных сущностей. А при использовании ORM уровня Entity Framework вы добавляете код для отображения сущностей на таблицы. Если говорить о NoSQL СУБД, для примера Neo4j, то там очень выразительный и мощный для своих задач язык. Но опять же это приведет к использованию процедурной парадигмы.
Насколько легко сменить выбранное решение?
Выводы
Из всего, что мы обсудили, можно сделать выводы:
При проектировании сервиса с нуля лучше сразу прогнозировать дальнейшее развитие этого сервиса и выбирать наиболее подходящее типовое решение.
Если дальнейшее развитие для сервиса не очевидно, то лучше сразу позаботиться о возможной смене парадигмы. Например, предпочитая eventual consistency. При добавлении нового функционала всегда держать в уме возможность смены решения.
Какие еще выводы вы могли бы предложить? Оставляйте ваши комментарии, давайте обсудим.