Гибридный подход выделения событий предметной области

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

Микросервисная архитектура позволяет разбить программу на блоки – микросервисы, каждый из которых способен работать автономно и связан с другими программными блоками посредством легковесных протоколов – REST, SOAP, gRPC или иными способами [1].

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

Кроме того, что растет требовательность к специалистам, занимающимся проектированием, растет и требовательность к инструментам, которые такие спе- циалисты могут использовать в работе. Одним из таких важных инструментов является Domain Driven Design (DDD).

DDD – это подход, который нацелен на изучение предметной области предприятия в целом или каких-то отдельных бизнес-процессов [3]. Этот подход применим для проектов, в которых сложность бизнес-логики достаточно велика. Его применение призвано снизить эту сложность, насколько возможно. Целью применения DDD является создание как можно более высококачественной модели предметной области с наилучшим возможным отображением бизнес-процессов этой предметной области.

В качестве инструментов описания биз-нес-процессов в DDD используется ряд техник, основанных на подходах, связанных с событийно-ориентированной архитектурой Event Driven Architecture (EDA) [4]. При этом в данных техниках отброшены классические подходы описания бизнес-процессов предметной области, таких как, например, описание бизнес-процессов в нотации IDEF0. В то же время, классические подходы не утратили свою эффективность, их применение в процессах проектирования остается актуальным, например, для векторизации процесса описания пути пользователя при проведении событийного штурма и увеличения количества контекста в рамках проектирования с использованием EDA.

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

Event Driven Architecture

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

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

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

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

Рис. 1. Результаты событийного штурма для сервиса покупки авиабилетов

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

IDEF0

IDEF0 – это методика функционального проектирования бизнес-процессов. Данная методология была создана для описания программных систем с помощью построения моделей. В IDEF0-модели есть только один субъект, единственная цель и одна точка зрения [6].

Цель – это набор вопросов, которые должна разрешить программная система. С точки зрения система описывается. На данный двух понятиях основывается вся методология IDEF0.

Построение модели организовано в виде иерархической структуре диаграмм. Вершина данной структуры – это наиболее обобщенное описание исходного программного продукта.

Основными правилами метода IDEF0 являются:

• 1)    Функциональный блок имеет входы и выходы. В ходе работы блока входные данные обрабатываются, выходные данные являются результатом этой обработки.

• 2)    Функциональный блок ограничен управляющими компонентами, которые задают условия работы блока.

• 3)    Механизмы непосредственно осуществляют обработку данных функциональным блоком.

На рисунке 2 продемонстрирована общая схема построения вершины иерархии моделей программной системы в рамках методологии IDEF0.

УПРАВЛЕНИЕ

МЕХАНИЗМ

Рис. 2. Общая схема вершины иерархии моделей программной системы по методу IDEF0

Построим для рассматриваемой программной системы для бронирования авиабилетов диаграмму по методу IDEF0. Результат показан на рисунке 3.

Рис. 3. Пример диаграммы IDEF0 для процесса бронирования авиабилетов

Совмещение подходов

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

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

Рис. 4. Пример диаграммы для процесса бронирования авиабилетов гибридным методом

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

Рис. 5. Пример диаграммы для процесса оплаты авиабилетов гибридным методом

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

Заключение

В рамках данной статьи был сделан обзор таких средств для разработки программного обеспечения, как подход Domain Driven Design, Event Driven

Architecture и нотация IDEF0. Отмечены сильные и слабые стороны перечисленных технологий. Предложен гибридный метод, объединяющий принципы построения модели программной системы IDEF0 и описание функционала системы методом событийного штурма. На примере системы по бронированию и покупки авиабилетов было продемонстрирована основная идея гибридного метода.