Дорогие читатели, в 100% случаев вы используете логику для того, чтобы разобраться в том, как работает продукт, который вы делаете и вам кажется, что именно это и есть UX. Основную часть того самого UX составляет бизнес-логика. Скорее всего вы спросите, почему дизайнера вообще должен волновать вопрос бизнеса. Ну логика-то ладно, а что такое бизнес-логика?
Давайте разберемся, что же такое бизнес-логика:
Бизнес-логика описывает работу всех бизнес-процессов, существующих в продукте.
Воу-воу-воу, полегче.. Это же и есть UX!
И да и нет. Под термином «Бизнес-логика» действительно понимают UX, но есть существенный нюанс.
Обычно к UX-дизайну относятся только пользовательские сценарии. Тогда как бизнес-логика описывает именно бизнес-процессы, происходящие под капотом UX с сугубо технической точки зрения.
Если бизнес-логика отвечает на вопрос:
«Как продукт должен работать технически?»
То UX-дизайн отвечает на вопрос:
«Как пользователь будет пользоваться продуктом и как сделать этот процесс максимально удобным и быстрым?».
Наглядная разница
UX-дизайн рассматривает ситуации (сценарии), с которыми сталкивается пользователь в процессе использования продукта; проблемы, которые продукт должен решить, чтобы им было интересно, выгодно или, как минимум, удобно пользоваться.
Бизнес-логика, наоборот, есть набор различных бизнес-процессов, возникающих внутри продукта. Они связаны между собой сугубо технически и никак не связаны с UX-дизайном.
UX-дизайн
То, как видит логику работы части приложения UX-дизайнер.
- Пользователь очень хочет смуззи!
- Он открывает приложение.
- Выбирает смуззи, указывает количество и нажимает кнопку «Купить»
- Ввводит адрес доставки, адрес проверяется, переходит к оплате смуззи.
- Оплачивает смуззи.
- Получает подтверждение покупки и видит информацию о дате и времени доставки, и ждет курьера.
Бизнес-логика
То, что должен видеть хороший UX-дизайнер и продакт менеджер.
- Пользователь авторизован / не авторизован
- Пользователь выбирает смуззи из всех доступных на данный момент
- Пользователь указывает характеристики смуззи
- Система проверяет, что для смуззи есть ингредиенты и запускает пользователя в процесс покупки смуззи.
- Пользователь указывает адрес доставки.
- Система проверяет условия доставки и можно ли вообще доставить смуззи за МКАД по указанному адресу.
- Пользователь переходит к оплате смуззи.
- Если пользователь авторизован, то его направляют на выбор способа оплаты.
- Если пользователь не авторизован, то его направляют на регистрацию.
- Пользователь выбирает способ оплаты.
- Пользователь указывает «Оплата наличными». Пользователь может выбрать и другой вариант.
- Пользователь указывает «Оплата банковской картой».
- Пользователь вводит данные банковской карты и нажимает на кнопку «Оплатить».
- Платежный шлюз проверяет реквизиты платежа
- Платежный шлюз принимает оплату и сообщает системе, что платеж принят.
- Заказ поступает в ближайшую к клиенту смуззишную.
- Заказ готовится.
- Заказ готов и передается курьеру.
- Курьер доставляет заказ пользователю.
- Курьер отмечает факт доставки заказа.
- Данные о завершении заказа попадают в систему.
- Система направляет пользователю предложение оценить сервис.
В реальной жизни бизнес-процесс устроен несколько сложнее, но общая идея и различие с UX-дизайном должны быть понятно.
Тэйк эвэй
Термин «Бизнес-логика» вы вряд ли услышите в стартапе, нацеленном на продажу смуззи, зато этот термин в широком ходу в B2B и интеграторах.
Теперь вас точно не испугаешь замысловатым вопросом «А как устроена бизнес-логика?». Помните, что бизнес-логика – это про весь механизм работы продукта, а UX-дизайном является лишь то, что по факту увидит пользователь в интерфейсе, в email и sms, отправленные вашим продуктом.
Всем бобра! ❤️
Источник: medium.com
Бизнес-логика в no-code: что это и как ее построить
Бизнес-логика приложения – это, по сути, описание схем, по которым приложение взаимодействует с пользователем. Когда пользователь оформляет подписку, или заполняет форму заказа, или просто авторизуется – все эти действия обрабатываются «под капотом» приложения в определенном порядке.
3697 просмотров
Какие данные нужно запросить? Соответствуют ли введенные данные заданному формату? Что произойдет после того, как пользователь нажмет кнопку «Подтвердить»? А есть ли вообще у него права доступа к данной операции? На все эти и многие другие вопросы можно ответить, изучив, как построена бизнес-логика конкретного приложения.
Простейший пример: администратор авиакомпании (пользователь) регистрирует пассажира на рейс (вносит информацию в базу данных).
Что делает пользователь:
1.Открывает информацию о выбранном рейсе, переходит к списку уже зарегистрированных пассажиров, нажимает «Зарегистрировать пассажира».
2.Заполняет форму регистрации: вводит номер рейса, выбирает пассажира, указывает место и статус регистрации.
3.Нажимает кнопку «Подтвердить»
4.Видит нового пассажира в общем списке.
Как это выглядит с точки зрения бизнес-логики приложения:
1.Приложение проверяет, авторизован ли пользователь и имеет ли права доступа к выбранной странице, а также операции регистрации.
2.Ждет, пока пользователь заполнит форму.
3.Обрабатывает введенные данные:
a. Проверяет, соответствуют ли введенные данные требованиям приложения (эти требования заранее прописаны программистом): например, в поле «Номер рейса» должно быть целое число.
b. Получает из базы данных информацию: например, о рейсе и связанных с ним регистрациях (чтобы внести изменения), пассажире (чтобы проверить, действительно ли этот пассажир есть в базе данных).
c. Выдает сообщения об ошибках, если поля заполнены неверно.
d. Отправляет информацию в базу данных, отдавая команды на создание в ней новых записей или обновлении существующих.
4.Выводит обновленную информацию на экран.
Общая логика приложения строится из бизнес-процессов – схем, описывающих конкретные операции в системе: создание записи о пассажире, добавление в систему нового рейса, редактирование информации о регистрации.
Когда речь идет о классическом программировании, то для описания всех процессов используются блоки кода. Многие из них пишутся по шаблонам – просто используются в разной последовательности и для работы с разными данными.
Именно благодаря этой «шаблонности» в no-code разработке появилась возможность использовать инструменты визуального программирования – так называемые дизайнеры бизнес-логики. Они помогают выбрать нужные блоки, скомпоновать в нужной последовательности, настроить. И даже создать некоторые блоки автоматически, в зависимости от настроек других компонентов приложения. Итог – готовая бизнес-логика без необходимости проводить многие часы над строками кода.
О том, как настраивать бизнес-логику на платформе Appmaster.io, вы можете узнать из видео о бизнес-процессах.
Источник: vc.ru
Блог .Net C# — программиста
Этот блог посвящен проектированию и разработке программного обеспечения с использованием технологий Microsoft .Net и языка C#.
Поиск по этому блогу
Что такое бизнес-логика в программировании?
Что такое бизнес-логика в программировании?
При проектировании и реализации программных систем часто сталкиваешься с такими понятиями как:
- Бизнес-логика;
- Бизнес-правила;
- Бизнес-ограничение;
- Бизнес-операция;
- и т.д.
Б изнес (англ. business — «дело», «предприятие») — деятельность, направленная на получение прибыли; любой вид деятельности, приносящий доход или иные личные выгоды (wiki). Данное определение не применимо в рамках реализации программного продукта, и не связано с какой-либо коммерческой деятельностью. Термин Бизнес можно заменить на понятие Предметная Область(ПО), от которого и надо отталкиваться.
Предметная область ( domain ) – это часть реального мира занимающееся деятельностью, которая служит объектом автоматизации (не путайте данное определение с понятием модели предметной области, до нее мы еще доберемся).
Разберем данное определение предметной области на примере городской библиотеки, где библиотека является частью реального мира, а её деятельность – учет имеющихся книг и выдача их читателям.
Создавая приложение для автоматизации деятельности библиотеки, необходимо определить какими данными, оно будет манипулировать. Вот примерный список бизнес-данных взятых из предметной области:
- Название книги
- Ф.И.О. автора
- Количество экземпляров данной книги
- Ф.И.О. читателя
- Дата рождения читателя
- Экземпляры книг, которые имеются у него на руках
- и т.д.
- Сценарий транзакций;
- Модуль таблицы;
- Модель предметной области.
Бизнес-правило – это положение, определяющее или ограничивающее какие-либо стороны бизнеса (предметной области). Его назначение – защитить структуру бизнеса, контролировать или влиять на его операции.
Бизнес-правила разделяют примерно на шесть основных категорий:
1. Бизнес-термины – фундаментальная форма бизнес-правила. Это фразы, слова, аббревиатуры из предметной области. Обычно такие термины хранятся в документе под названием «бизнес глоссарий» или «словарь терминов». Примеры бизнес-терминов: читатель; к нига; I SBN ( англ . International Standard Book Number , сокращённо — англ . ISBN ) — уникальный номер книжного издания ; читательский абонемент – документ, где учитываются книги выданные читателю; и т.д.
2. Факты (facts) — это верные утверждения о бизнесе. Зачастую они описывают связи и отношения между важными бизнес-терминами. Факты также называют инвариантами — неизменными истинами о сущности данных и их атрибутах. Бизнес-правила во многих случаях могут ссылаться на определенные факты, однако последние обычно не преобразуются напрямую в функциональные требования к программному обеспечению. Сведения о сущности данных, важных для системы, применяют в моделях данных, создаваемых аналитиком или архитектором базы данных.
- каждая книга должна иметь международный стандартный книжный номер;
- клиент оплачивает доставку каждого заказа;
- заказ должен содержать не менее одной позиции;
- блиц-цена лота аукциона устанавливается продавцом;
- каждый авиарейс имеет аэропорт вылета и аэропорт прилета;
- автосалон реализует автомобили нескольких производителей (является мультибрэндовым дилером).
3. Ограничения ( constraints ) — определяют, какие операции может выполнять система и ее пользователи. Вот некоторые слова и фразы, которые применяются при описании ограничивающего бизнес-правила: должен / не должен, может / не может , только .
- постоянный посетитель библиотеки может отложить для себя до 10 книг;
- сотрудник может запросить вещество из списка химикатов первого уровня опасности, только если за последние 12 месяцев он прошел обучающий курс работы с опасными соединениями;
- все программы должны соответствовать правительственным постановлениям, касающимся использования их людьми с ослабленным зрением;
- экипажи коммерческих авиарейсов должны каждые 24 часа отдыхать не менее 8 часов;
- возраст участника аукциона должен превышать 18 лет;
- автосалон может обменять старый автомобиль клиента на новый с минимальными для клиента финансовыми потерями.
Как правило, в целевой организации существуют политики безопасности, определяющие порядок доступа к информационным системам. Обычно они констатируют, какие пароли следует применять, как часто их необходимо менять, можно ли применять старые пароли и т.д. Все эти ограничения, касающиеся доступа к приложению, можно считать бизнес-правилами. Ввод каждого такого правила в конкретный код упрощает обновление систем, необходимое для соответствия их новым правилам. Например, изменение необходимой частоты обновления паролей с 90 до 30 дней.
4. Активатором операции ( action enabler ) называется бизнес-правило, приводящее к выполнению каких-либо действий при определенных условиях. Человек может выполнять эти действия вручную. Иногда правило может управлять некоторыми функциями программы, благодаря которым приложение при выполнении определенных условий реализует нужную модель поведения. Выражение вида «Если , то »— это ключ, который описывает активатор операции.
- если на складе имеются контейнеры с запрошенным химикатом, их следует предложить запросившему химикат лицу;
- если срок хранения контейнера с химикатом истек, необходимо уведомить лицо, у которого в данный момент находится контейнер;
- если клиент заказал книгу автора, написавшего несколько книг, клиенту следует предложить другие книги этого автора, прежде чем принять заказ;
- если на запрошенную клиентом дату вылета рейс не выполняется, необходимо предоставить ему расписание вылетов по данному направлению;
- если к моменту проведения расчетов с победителем аукциона его лицевой счет не содержит нужной суммы, право приобретения лота переходит к лицу, сделавшему вторую лучшую ставку;
- если клиент подал корректную заявку на прохождение тест-драйва, необходимо связаться с ним по телефону для согласования деталей.
5. Выводы ( inference ) , иногда называемые предположительным знанием — это правила, устанавливающие новые реалии на основе достоверности определенных условий. Вывод создает новый факт на основе других фактов или вычислений. Выводы зачастую записывают в формате «если — то», применяемом также при записи бизнес-правил, активирующих операции. Тем не менее, раздел «то» вывода заключает в себе факт или предположение, а не действие.
- если поставщик не может поставить заказанный товар в течение пяти дней с момента получения заказа, заказ считается невыполненным;
- считается, что срок хранения контейнеров с химикатами, разлагающимися на взрывоопасные составляющие, истекает через один год c даты изготовления;
- если выставленный участнику аукциона счет не был оплачен в течение трех дней с момента окончания аукциона, счет считается просроченным;
- если привезенный автосалоном под заказ автомобиль не был выкуплен клиентом в течение 10 дней, автомобиль считается находящимся в свободном наличии;
- если в расписании зимнего сезона отсутствуют сведения о рейсе, выполняемом в летний период, рейс считается отмененным на весь период действия нового расписания.
- цена единицы товара снижается на 10% при заказе от 6 до 10 единиц, на 20% — при заказе от 11 до 20 единиц и на 30% — при заказе свыше 20 единиц;
- стоимость автомобиля «Opel» в салоне рассчитывается путем сложения стоимости базовой модели, стоимости выбранных покупателем пакетов, стоимости опций, за минусом скидки при повторной покупке в салоне, и скидки корпоративного клиента, но при условии, что продаваемый автомобиль не реализуется по акции «КАСКО в подарок».
- если выбранная клиентом комплектация автомобиля содержит пакеты опций, стоимость пакетов добавляется к стоимости базовой комплектации;
- если выбранная клиентом комплектация автомобиля содержит опции, стоимость опций добавляется к стоимости базовой комплектации;
- если клиент совершает повторную покупку, стоимость автомобиля уменьшается пропорционально скидке постоянного клиента;
- если клиент является корпоративным, стоимость автомобиля уменьшается пропорционально скидке корпоративного клиента;
- скидки корпоративного и постоянного клиента суммируются;
- если автомобиль реализуется по акции «КАСКО в подарок», скидки корпоративного и постоянного клиента не действуют.
Эти бизнес-правила называются элементарными потому, что дальнейшая их детализация невозможна. В конечном итоге скорее всего, будет создано множество элементарных бизнес-правил, от комбинаций которых будут зависеть все вычисления и функциональные требования.
Рассмотрим пример бизнес-логики, которая реализует следующее бизнес-правило: возраст читателя должен быть от 7 и до 21 года. Данное правило можно реализовать например при регистрации пользователя в нашей системе. В примере ниже последние несколько строк реализуют это правило, а код повыше является вспомогательным для получения возраста и к предметной области никак не относится.
Источник: proggerdotnet.blogspot.com
