Простой способ определения бизнес-логики

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

Business Logic — это бьющееся сердце любой программной системы. Тем не менее, многим разработчикам программного обеспечения нужна помощь в его идентификации. Если мы коллективно хотим создавать (и поддерживать!) программы, с которыми легко работать, нам нужно хорошо справляться с этой единственной задачей. И у меня есть отличный трюк, который поможет вам уверенно указать на критическую логику любого бизнес-процесса.

Давайте посмотрим на пример.

Новая функция

Представьте, что вы получили следующие требования для процесса регистрации нового клиента:

Требование: зарегистрировать нового клиента

Обзор:

Новые клиенты должны иметь возможность безопасно регистрироваться в нашей системе с помощью наших мобильных и веб-приложений через новый веб-API RESTful.

Подробные шаги:

1. HTTP POST информацию о клиенте в конечную точку API с защитой OAuth2 /customers.
2. Проверка полученной информации о клиенте. В частности, проверьте наличие обязательных полей, таких как имя, фамилия и адрес электронной почты.
3. Если клиент уже существует (по адресу электронной почты) в базе данных SQL Server, это ошибка. Вернуть код состояния HTTP «409 - Conflict».
4. В противном случае сохраните клиента с уникальным идентификатором в базе данных.
5. После успешной регистрации отправьте клиенту приветственное сообщение по электронной почте.
6. Вернуть клиента, включая уникальный идентификатор, мобильным или веб-клиентам с кодом состояния HTTP «201 - Created».

Хорошо, это имеет смысл и кажется разумным, хотя похоже, что архитектор взвесил особенности технологии.

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

Хорошо, вы можете присоединиться к этой идее.

Но какие части требования относятся к бизнес-логике?

Время изменить перспективу.

Бумажная процедура

Как бы выглядел этот бизнес-процесс, скажем, 50 или 100 лет назад?

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

1. Потенциальный клиент заполняет бумажную регистрационную форму,
2. Клиент передает форму помощнику (или владельцу бизнеса) для проверки,
3. Ассистент проверяет, что клиент заполнил форму полностью и правильно. В противном случае он возвращается заказчику для устранения ошибок и упущений.
4. Затем помощник проверяет, является ли человек уже клиентом, ища его в картотеке записей клиентов.
5. Если клиент уже существует, регистрация прекращается — нет смысла создавать дубликат записи клиента. Естественно, помощник сообщает человеку, что он уже является зарегистрированным клиентом.
6. Если помощнику не удается найти клиента среди записей клиентов, он записывает уникальный номер клиента в поле «Номер клиента только для офиса».
7. Помощник хранит новую запись о клиенте в картотеке.
8. Наконец, помощник информирует клиента о том, что он зарегистрирован и может приобретать товары и услуги.
9. Сделанный!

Считаете ли вы упражнение по визуализации бумажного бизнес-процесса полезным для определения базовой бизнес-логики в автоматизированном рабочем процессе с помощью программного обеспечения? Нет?

Бизнес-логика описывает ЧТО происходит, а не КАК это происходит.

И компьютерные, и бумажные процессы пытаются достичь одной и той же цели — одного и того же ЧТО — но они делают это разными средствами — или КАК.

Что общего?

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

Подробные шаги:

1. HTTP POST информацию о клиенте в конечную точку /customers API, защищенную OAuth2.
2. Проверьте полученную информацию о клиенте. В частности, проверьте наличие обязательных полей, таких как имя, фамилия и адрес электронной почты.
3. Если клиент уже существует (по адресу электронной почты) в базе данных SQL Server, это ошибка. Вернуть код состояния HTTP «409 — Конфликт».
4. В противном случае сохраните клиента с уникальным идентификатором в базе данных.
5. После успешной регистрации отправьте клиенту приветственное письмо по электронной почте сообщение.
6. Вернуть клиента, включая уникальный идентификатор, в мобильные или веб-клиенты с кодом состояния HTTP «201 — Создано».

Обратите внимание, как исчезают все детали HTTP. HTTP и Интернет являются особыми механизмами доставки и не являются частью бизнес-логики. Должна ли регистрация клиента осуществляться через HTTP? Нет, конечно нет. Вместо этого мы могли бы выбрать другой механизм доставки, возможно, службу Windows или консольное приложение. Детали HTTP относятся к системе в целом, но не относятся к компоненту бизнес-логики этой системы.

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

То, что база данных будет именно SQL Server, не касается бизнес-логики. Да, должен быть механизм для сохранения данных о клиентах, но то, как мы этого добьемся, не является обязанностью бизнес-логики.

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

Когда регистрация клиента прошла успешно, мы отправляем клиенту приветственное сообщение. Критически важно, что это не приветственное электронное письмо. Почему? Потому что электронная почта — это механизм. Конечно, мы отправим приветственное уведомление, но это может быть не электронное письмо — это может быть сообщение SMS/TXT, уведомление в приложении, сообщение Slack или Discord и так далее.

Не бизнес-процесс

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

Заключение

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

Если вам понравилась эта статья, пожалуйста, поставьте несколько аплодисментов — и кучу аплодисментов, если она вам понравилась! :) Большое спасибо.

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

При регистрации вы получите мое руководство "Путь к мастеру-программисту", содержащее 3 мощные идеи, которые помогут вам сократить путь к профессиональному программисту.