Перейти к основному содержимому

7.01. Бизнес-логика

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ
Руководителю Аналитику Техническому писателю

Бизнес-логика​

Что такое бизнес-логика?​

Бизнес-логика — это набор правил, ограничений и процедур, определяющих поведение системы в соответствии с требованиями бизнеса. Бизнес-логика воплощает суть операций организации: как обрабатываются заказы, как рассчитываются скидки, как утверждаются документы.

Бизнес-логика устроена как иерархия правил разного уровня:

  • стратегические правила: политика ценообразования, условия сотрудничества
  • операционные правила: последовательность шагов в процессе, критерии принятия решений
  • тактические правила: обработка исключительных ситуаций, эскалация проблем
  • валидационные правила: проверка корректности данных и соблюдения ограничений

Бизнес-логика реализуется в программном коде, конфигурациях систем или описаниях процессов. Отделение бизнес-логики от технической реализации повышает гибкость системы и упрощает адаптацию к изменениям в бизнес-требованиях.

Система электронной коммерции содержит бизнес-логику расчёта итоговой стоимости заказа. Правила логики определяют последовательность применения скидок: сначала учитываются промокоды, затем накопительные скидки за объём покупок, после этого рассчитывается стоимость доставки в зависимости от региона и веса заказа, и в конце добавляется налог. Для постоянных клиентов применяется дополнительная скидка лояльности. Если общая сумма заказа превышает порог бесплатной доставки, стоимость доставки обнуляется. Система проверяет наличие товаров на складе и блокирует оформление заказа при отсутствии критически важных позиций. Каждое правило реализовано как отдельный компонент, что позволяет изменять политику скидок без переписывания основной логики расчёта.

public class OrderCalculator
{
    public decimal CalculateTotal(Order order, Customer customer)
    {
        decimal baseAmount = order.Items.Sum(item => item.Price * item.Quantity);
        
        decimal promoDiscount = ApplyPromoCodeDiscount(baseAmount, order.PromoCode);
        decimal volumeDiscount = ApplyVolumeDiscount(baseAmount - promoDiscount, order.TotalItems);
        decimal loyaltyDiscount = ApplyLoyaltyDiscount(baseAmount - promoDiscount - volumeDiscount, customer.LoyaltyLevel);
        
        decimal subtotal = baseAmount - promoDiscount - volumeDiscount - loyaltyDiscount;
        decimal shippingCost = CalculateShippingCost(order.DeliveryAddress, order.TotalWeight, subtotal);
        decimal tax = CalculateTax(subtotal + shippingCost, order.DeliveryAddress.Region);
        
        return subtotal + shippingCost + tax;
    }
}
def calculate_order_total(order, customer):
    base_amount = sum(item.price * item.quantity for item in order.items)
    
    promo_discount = apply_promo_code_discount(base_amount, order.promo_code)
    volume_discount = apply_volume_discount(base_amount - promo_discount, order.total_items)
    loyalty_discount = apply_loyalty_discount(base_amount - promo_discount - volume_discount, customer.loyalty_level)
    
    subtotal = base_amount - promo_discount - volume_discount - loyalty_discount
    shipping_cost = calculate_shipping_cost(order.delivery_address, order.total_weight, subtotal)
    tax = calculate_tax(subtotal + shipping_cost, order.delivery_address.region)
    
    return subtotal + shipping_cost + tax
public class OrderCalculator {
    public BigDecimal calculateTotal(Order order, Customer customer) {
        BigDecimal baseAmount = order.getItems().stream()
            .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))
            .reduce(BigDecimal.ZERO, BigDecimal::add);
        
        BigDecimal promoDiscount = applyPromoCodeDiscount(baseAmount, order.getPromoCode());
        BigDecimal volumeDiscount = applyVolumeDiscount(baseAmount.subtract(promoDiscount), order.getTotalItems());
        BigDecimal loyaltyDiscount = applyLoyaltyDiscount(
            baseAmount.subtract(promoDiscount).subtract(volumeDiscount), 
            customer.getLoyaltyLevel()
        );
        
        BigDecimal subtotal = baseAmount.subtract(promoDiscount)
                                        .subtract(volumeDiscount)
                                        .subtract(loyaltyDiscount);
        BigDecimal shippingCost = calculateShippingCost(order.getDeliveryAddress(), order.getTotalWeight(), subtotal);
        BigDecimal tax = calculateTax(subtotal.add(shippingCost), order.getDeliveryAddress().getRegion());
        
        return subtotal.add(shippingCost).add(tax);
    }
}

Каждая реализация следует одной и той же бизнес-логике: последовательное применение скидок, расчёт доставки и налогов. Различия проявляются только в синтаксисе языка программирования, что подчёркивает отделение бизнес-правил от технической реализации.

Бизнес функционирует как целостная система, где индустрия определяет контекст, рынок задаёт условия конкуренции, а бизнес-модель описывает способ создания ценности. Бренд формирует восприятие продукта, маркетинг привлекает клиентов, продажи конвертируют интерес в сделки. Логистика обеспечивает доставку, цена отражает баланс затрат и ценности, а бизнес-логика воплощает правила работы в цифровых системах. Корпорация предоставляет организационную форму, реализация превращает планы в результаты, а бюрократия и монополизация влияют на эффективность и конкуренцию в системе.

Эффективный бизнес постоянно балансирует между внутренней организацией процессов и адаптацией к внешним изменениям рынка, технологий и потребительских предпочтений.

Менеджер​

Менеджер — это специалист, отвечающий за планирование, организацию, координацию и контроль деятельности команды или проекта для достижения поставленных целей. Менеджер выступает связующим звеном между бизнесом и исполнителями, обеспечивая преобразование стратегических задач в конкретные рабочие планы.

Менеджер устроен как центр управления потоками:

  • сбор и анализ требований от заинтересованных сторон
  • приоритизация задач и распределение ресурсов
  • координация работы специалистов разных профилей
  • мониторинг прогресса и управление рисками
  • коммуникация с заказчиками и стейкхолдерами
  • принятие оперативных решений в рамках полномочий

В проектах разработки программного обеспечения менеджер обеспечивает соблюдение сроков, бюджета и качества, управляя ожиданиями всех участников процесса. Эффективный менеджер сочетает техническое понимание предметной области с навыками управления людьми и процессами.

Требование​

Как менеджер, так и аналитик, работают с таким понятием, как требование – представление потребности, пригодное для использования. Оно сосредоточено на понимании того, какая ценность может быть получена в результате выполнения требования. Кто-то называет это спецификацией – словом, это то, что должно быть реализовано в процессе. В нашем случае – в процессе разработки.

Требования могут быть конкретизированными, общими, или какими-то специфичными, вроде требований к функционалу, приёмке. Это некое описание, которое отражает потребность.

Требование — это формализованное описание потребности, пригодное для использования в процессе разработки или внедрения решения. Требование фиксирует ожидания заинтересованных сторон относительно функциональности, качества или ограничений будущей системы.

Требование устроено как структурированное утверждение, содержащее:

  • субъект: кто или что предъявляет требование
  • действие: что система должна делать или как должна вести себя
  • объект: над чем или с чем выполняется действие
  • условия: при каких обстоятельствах требование применяется
  • критерии проверки: как будет подтверждено выполнение

Примеры требований разного уровня детализации:

  • бизнес-требование: «Система должна сократить время обработки заказа до 5 минут»
  • пользовательское требование: «Покупатель может отменить заказ до момента передачи курьеру»
  • функциональное требование: «При нажатии кнопки "Отмена" система проверяет статус заказа и при значении "Собран" устанавливает статус "Отменён"»

Требования становятся основой для проектирования, разработки и тестирования, обеспечивая единое понимание целей проекта всеми участниками.

Потребность​

Потребность — это осознанная нехватка чего-либо, требующая устранения для достижения желаемого состояния или решения проблемы. Потребность возникает из разрыва между текущим положением дел и ожидаемым результатом.

Потребность устроена как триада:

  • источник: кто испытывает потребность (пользователь, бизнес, система)
  • суть: в чём проявляется нехватка (время, ресурсы, функциональность)
  • мотивация: почему важно устранить эту нехватку (выгода, снижение рисков, соответствие нормам)

Потребности трансформируются в требования через процесс анализа и формализации. Например, потребность «мне неудобно искать нужные документы в папках» может быть преобразована в требование «Система должна предоставлять поиск документов по ключевым словам с результатами за менее чем 2 секунды».

Понимание истинной потребности, а не только поверхностного запроса, позволяет создавать решения, действительно решающие проблемы пользователей и бизнеса.

Конкретика​

Конкретика — это степень детализации и определённости в описании, исключающая двусмысленность и допускающая однозначную интерпретацию. Конкретика превращает абстрактные идеи в измеримые и проверяемые утверждения.

Конкретика устроена через применение измеримых параметров:

  • количественные показатели: «время загрузки не более 3 секунд» вместо «быстрая загрузка»
  • чёткие границы: «поддержка браузеров не старше двух лет» вместо «поддержка современных браузеров»
  • конкретные сценарии: «пользователь вводит номер телефона, система отправляет СМС с кодом, пользователь вводит код» вместо «удобная авторизация»
  • определённые роли: «администратор магазина» вместо «ответственное лицо»

Высокая конкретика снижает риски недопонимания между заказчиком и исполнителем, упрощает оценку трудозатрат и позволяет точно проверить выполнение требований. Требования без конкретики часто приводят к спорам при приёмке и необходимости доработок.

Основы теории требований​

Дизайн​

В английском языке есть понятие design (дизайн), которое как может подразумевать «оформление», так и проектирование. По нашему пониманию проще воспринимать отдельно дизайн как оформление, а касательно проектирования – проект. Дизайн и требования – похожие вещи, но дизайн это вроде конкретного варианта реализации решения, тогда как требование – просто может быть общим изложением.

Требования могут изложить просто в сообщении в мессенджере, вроде «хочу сайт, который будет генерировать мне случайные фильмы для просмотра на вечер». А могут быть в виде огромного технического задания с подробным описанием всех полей, структур, с примерами дизайна сайта, а также перечнем сопутствующих вопросов, которые нужно будет решить.

Уровни требований​

Выделяют три уровня требований:

  • бизнес-требования;
  • требования пользователей;
  • требования к решению.

Бизнес-требования же отличаются тем, что они формулируют цели, задачи, результаты разработки, без углубления в технические моменты. Как раз AS IS, TO BE. Туда можно включать бизнес-цели, концепцию решения, какие-то рамки и границы, критерии готовности, описания пользователей. Словом, общий контекст.

Бизнес-правила​

Бизнес-требования могут в себе содержать бизнес-правила, определяющие или ограничивающие конкретные моменты.

Пример бизнес-правила – заявитель должен быть совершеннолетним. В таком случае, бизнес-требования будут содержать это правило, а команде разработки придётся реализовать техническими средствами проверку на соответствие этим условиям (валидация).

Бизнес-правило является условием поведения системы или её конкретных элементов.

Пользовательские требования​

Требования пользователей, или пользовательские требования – описание с точки зрения выполнения сценария, через два варианта:

  • User Story – пользовательская история, которая приводит пример, играя роль соответствующего пользователя, при этом короткая, простая и акцентируется на потребностях пользователя, без деталей - «Как [роль], я хочу [действие], чтобы [цель/выгода]. »;
  • Use Case – более детальный сценарий, указывающий уже «как» должна вести себя система, указав роль, цель, шаги и альтернативные потоки, к примеру, «покупатель жмёт кнопку, система выводит окно с подтверждением, если да – выполняет, если нет – возвращается на шаг назад».

Требования к решению​

Требования к решению, или спецификация включает в себя:

  • функциональные требования (описание поведения системы по данной функции – самые детальные особенности именно тут);
  • нефункциональные требования:
    • требования к данным – объектная модель, связи, атрибуты, свойства;
    • требования к интерфейсу (пользовательский интерфейс, внешний вид);
    • ограничения (какие-то особые условия, допустим набор технологий);
    • системные требования (требования к программному обеспечению и оборудованию, на котором будет функционировать разработанное решение);
    • показатели качества (удобство использования, производительность, доступность, безопасность).

Все требования, как правило, документируют по завершению анализа, потом проверяют на соответствие бизнес-цели и верифицируют.

Функционал​

Функционал — это совокупность действий, операций и возможностей, которые система предоставляет пользователям для решения их задач. Функционал определяет, что система умеет делать и как пользователи взаимодействуют с её возможностями.

Функционал устроен как иерархия возможностей:

  • базовый функционал: критически важные операции без которых система неработоспособна
  • основной функционал: ключевые возможности, ради которых система создаётся
  • дополнительный функционал: вспомогательные возможности, улучшающие удобство использования
  • сервисный функционал: операции поддержки, администрирования и мониторинга

Пример функционала интернет-магазина:

  • просмотр каталога товаров
  • добавление товаров в корзину
  • оформление заказа с указанием адреса доставки
  • оплата банковской картой
  • отслеживание статуса заказа
  • управление личным кабинетом
  • администрирование товаров и заказов

Функционал документируется в функциональных требованиях и становится основой для проектирования интерфейсов, разработки модулей и составления тестовых сценариев.

Приёмка​

Приёмка — это процесс проверки и подтверждения соответствия разработанного решения утверждённым требованиям с последующим принятием решения о вводе в эксплуатацию. Приёмка завершает цикл разработки и передаёт ответственность за систему от команды разработки к эксплуатирующей стороне.

Приёмка устроена как последовательность этапов:

  • подготовка: сбор документации, подготовка тестовых данных и окружения
  • выполнение тестов: проверка функциональности согласно критериям приёмки
  • фиксация результатов: документирование выявленных расхождений и подтверждённых соответствий
  • устранение замечаний: доработка системы до достижения соответствия требованиям
  • подписание акта: формальное подтверждение готовности системы к эксплуатации

Критерии приёмки формулируются заранее и описывают конкретные условия, при которых функция считается принятой. Например: «После оформления заказа пользователь получает электронное письмо с подтверждением в течение 1 минуты, письмо содержит номер заказа, состав товаров и итоговую сумму».

Успешная приёмка подтверждает, что система решает поставленные бизнес-задачи и готова к использованию конечными пользователями.

Описание​

Описание — это текстовое или визуальное представление сущности, процесса или явления, передающее его существенные характеристики и особенности. Описание служит инструментом коммуникации между участниками проекта, обеспечивая единое понимание предмета обсуждения.

Описание устроено через комбинацию элементов:

  • контекст: обстановка или условия, в которых существует описываемый объект
  • структура: составные части и их взаимосвязи
  • поведение: как объект функционирует или взаимодействует с окружением
  • атрибуты: измеримые характеристики и свойства
  • ограничения: рамки и условия применения

В разработке программного обеспечения описания принимают разные формы:

  • описание требований: что система должна делать
  • описание архитектуры: как устроена система на высоком уровне
  • описание интерфейса: как пользователь взаимодействует с системой
  • описание данных: структура и взаимосвязи информации в системе

Качественное описание позволяет новым участникам проекта быстро вникнуть в суть, снижает количество уточняющих вопросов и служит основой для принятия проектных решений.

Критерии​

Критерии — это заранее определённые показатели или условия, по которым оценивается соответствие объекта ожидаемым требованиям или стандартам качества. Критерии превращают субъективные оценки в объективные измерения.

Критерии устроены как набор проверяемых утверждений:

  • измеримость: возможность количественной или качественной оценки
  • однозначность: отсутствие двусмысленности в трактовке
  • проверяемость: возможность подтвердить выполнение фактами
  • релевантность: связь с целями проекта или бизнеса

Примеры критериев разных типов:

  • критерии приёмки: «Форма регистрации сохраняет данные при потере интернет-соединения и отправляет их после восстановления связи»
  • критерии качества: «Время отклика интерфейса не превышает 200 миллисекунд при нагрузке до 1000 одновременных пользователей»
  • критерии готовности: «Все критические баги исправлены, покрытие автотестами основных сценариев составляет не менее 70%»

Критерии применяются на всех этапах проекта: при планировании для определения объёма работ, при разработке для проверки промежуточных результатов, при тестировании для верификации функциональности, при приёмке для подтверждения готовности к эксплуатации.

Верификация​

Верификация — это процесс проверки соответствия продукта разработки установленным требованиям и спецификациям на каждом этапе жизненного цикла. Верификация отвечает на вопрос «Правильно ли мы делаем продукт?», подтверждая, что текущая реализация соответствует задуманному замыслу.

Верификация устроена как многоуровневая система проверок:

  • проверка требований: полнота, непротиворечивость, измеримость
  • проверка проектной документации: соответствие архитектурным принципам и требованиям
  • проверка кода: соответствие стандартам, отсутствие уязвимостей, покрытие тестами
  • проверка сборки: корректность компиляции, отсутствие ошибок развёртывания
  • проверка интеграции: корректность взаимодействия компонентов системы

Верификация отличается от валидации: верификация подтверждает соответствие спецификации («делаем ли мы продукт правильно»), тогда как валидация подтверждает соответствие потребностям пользователя («делаем ли мы правильный продукт»).

Примеры верификационных действий:

  • анализ кода статическими анализаторами на соответствие стандартам
  • проверка покрытия кода юнит-тестами
  • сравнение поведения системы с описанными в требованиях сценариями
  • аудит документации на полноту и непротиворечивость

Регулярная верификация на ранних этапах позволяет выявлять отклонения от требований до того, как они превратятся в дорогостоящие ошибки на этапе приёмки или эксплуатации.

Бизнес-логика воплощается через взаимосвязанную систему понятий. Менеджер собирает потребности заинтересованных сторон и трансформирует их в требования с необходимой конкретикой. Аналитик детализирует требования, выделяя функционал и определяя критерии проверки. Разработчики реализуют функционал согласно описаниям, а тестировщики проводят верификацию соответствия реализации требованиям. Завершающим этапом становится приёмка, подтверждающая готовность системы решать бизнес-задачи.

Эффективная работа с бизнес-логикой требует чёткого понимания каждого термина, его места в процессе и взаимосвязей с другими элементами системы разработки. Отсутствие ясности в базовых понятиях приводит к коммуникационным барьерам, ошибкам в реализации и конфликтам при приёмке результатов.

Освоение главы0%