Содержание курса
Архитектура прикладных решений. Область разработки прикладных систем
Графический язык моделирования ArchiMate. Продолжение.
7.2.3. Элементы уровня приложений
Элементы уровня приложений (Application Layer) описывают программные компоненты, сервисы и данные, которые непосредственно поддерживают бизнес-процессы. Это "мост" между бизнес-активностями и технологической инфраструктурой.
Метамодель ArchiMate для уровня приложений рассматривает три ключевых аспекта:
1) Активные структурные элементы (Application Internal Active Structure Elements)
Это программные компоненты, которые выполняют действия.
Компонент приложения (Application Component). Модульная, независимо разворачиваемая часть программной системы. Это ключевой и наиболее часто используемый элемент для моделирования структуры приложения.
Компонента приложения выполняет одну или несколько функций приложения. Она инкапсулирует свое содержимое и предоставляет функциональные возможности только через набор интерфейсов приложений.
Примеры: Система CRM, модуль расчёта зарплаты, веб-сервис аутентификации, микросервис "Корзина покупок".
Ключевые характеристики и правила использования:
a) Самостоятельность (Modularity): Компонент представляет собой единицу, которую можно разрабатывать, покупать, заменять или разворачивать независимо в некоторой степени от других компонентов.
b) Инкапсуляция: Внутренняя структура и реализация компонента скрыты от внешнего мира. Взаимодействие происходит только через интерфейсы.
c) Функциональная целостность: Компонент реализует логически связанный набор функций. Его имя, как правило, является существительным, отражающим его основное назначение (например, "Платежный шлюз", а не "Обработать платеж").
d) Уровень детализации: Компонент может быть декомпозирован (разбит) на более мелкие, вложенные компоненты. Уровень детализации выбирается архитектором в зависимости от целей модели.
Основные отношения (связи) компонента приложения:
i. С элементами Поведения (что делает компонент).
a) Реализует Сервис (Realization).
b) Состоит из Функций/Процессов (Composition или Assignment)
ii. С элементами Структуры (как компонент устроен и взаимодействует):
a) Предоставляет/Требует Интерфейсы (Assignment)
b) Состоит из других Компонентов (Composition или Aggregation)
iii. С другими уровнями (как компонент связан с бизнесом и "железом"):
a) С Бизнес-уровнем (Serving)
b) С Технологическим уровнем (Realization или Assignment)
Интерфейс приложения (Application Interface). Точка доступа, через которой компонент приложения предоставляет свои услуги другим компонентам (внутри уровня) или внешним субъектам (бизнес-акторам, другим системам). По существу - это "фасад" компонента.
Обычно именуется по тем данным, которые через этот интерфейс проходят (существительное), например, "обмен данными транзакции".
Важно не путать Интерфейс с Сервисом:
© Сервис (Service) — это ЧТО делается (логическая функциональность, бизнес-ценность).
© Интерфейс (Interface) — это КАК это можно получить (технический контракт, протокол).
Примеры: REST API, SOAP-веб-сервис, графический пользовательский интерфейс (GUI), библиотека API.
Типовые отношения (связи):
a) С компонентом-владельцем (Assignment). Это основное отношение. Интерфейс назначается (is assigned to) Компоненту, который его предоставляет.
b) С сервисом (Realization). Интерфейс реализует один или несколько Сервисов. Через этот интерфейс потребитель получает доступ к сервисам.
c) С потребителем (Serving или Flow). Другой Компонент использует (serves) Интерфейс для доступа к функциональности.
Например, связки элементов могут учитывать такие варианты:
a) Бизнесу нужна возможность: [Business Process] требует выполнения задачи.
b) Приложение предоставляет сервис: [Application Service] обслуживает (serves) бизнес-процесс.
c) Сервис реализуется компонентом: [Application Component] реализует (realizes) этот сервис.
d) Компонент предоставляет интерфейс: [Application Interface] назначается (assigns) компоненту.
e) Интерфейс предоставляет доступ к сервису: Тот же интерфейс реализует (realizes) сервис.
f) Другие компоненты используют интерфейс: [Другой Application Component] использует (serves) этот интерфейс для получения сервиса.
Основные возможности использования интерфейсов:
a) Фиксация контрактов между компонентами.
b) Декомпозиция сложности — скрывает реализацию за фасадом.
c) Обозначение точек интеграции и потенциальных зависимостей.
d) Проектирование заменимостей — компонент можно заменить, если новый реализует те же интерфейсы.
Используя рассмотренные выше элементы, на базовой структурной диаграмме можно продемонстрировать: структуру приложений, кто какие интерфейсы предоставляет, какими данными оперируют компоненты.
Коллаборация приложения (Application Collaboration). Временное объединение двух или более компонентов приложения, которые взаимодействуют для выполнения конкретной общей функции, процесса или сервиса.
Ведет себя так же, как программная компонента, только назначается на функционал связки программ или кооперативные процессы. Определяет, какие компоненты взаимодействуют для выполнения некоторой задачи. "Виртуальная группа" компонентов, которая образуется для решения определенной задачи, а затем распадается. Коллаборация существует ровно столько, сколько длится это взаимодействие.
Пример: Коллаборация между "Сервисом заказов", "Сервисом склада" и "Платежным шлюзом" для обработки нового заказа.
Типовые отношения (связи):
a) Состоит из компонентов (Assignment или Aggregation). Компоненты назначаются (assigned to) коллаборации, играя в ней определенные роли.
b) Реализует поведение (Realization): Коллаборация реализует (realizes) Сервис, Функцию или Процесс приложения. Это её основная цель.
c) Может предоставлять интерфейс (Assignment): Коллаборация, как и компонент, может иметь свой интерфейс для взаимодействия с внешним миром.
Коллаборация показывается как пунктирная рамка вокруг компонентов, внутри показываются потоки взаимодействия (номерация вызовов), снаружи — реализуемые сервисы.
2) Элементы поведения (Application Behavior Elements)
Описывают, что делают активные структурные элементы.
Функция приложения (Application Function). Единица внутреннего поведения компонента приложения, которая представляет собой логически связанную группу действий, выполняемых компонентом для достижения определенного результата.
Если такое поведение подвергается внешнему воздействию, это делается через одну или несколько служб. Функция приложения абстрагируется от способа ее реализации. Указывается только то, что необходимо для описания поведения.
Примеры: "Проверить кредитоспособность", "Сформировать отчёт", "Зашифровать данные". Часто соответствует техническим требованиям.
Ключевые отношения:
a) Входит в состав компонента (Assignment или Composition). Функция назначается компоненту приложения. Она является частью его внутренней структуры.
b) Реализует сервис (Realization). Одна или несколько функций реализуют сервис приложения. Это показывает, как внешне видимый сервис выполняется внутри.
c) Использует объекты данных (Access). Функция получает доступ к объектам данных (читает, создает, изменяет).
d) Взаимодействует с другими функциями (Flow или Triggering). Функции могут вызывать друг друга, образуя поток управления внутри компонента.
Все функции находятся внутри компонента и не видны снаружи. Клиент видит только сервис. Если функции взаимодействуют между разными компонентами — это уже взаимодействие на уровне коллаборации.
Практические сценарии использования:
a) Декомпозиция сложной логики: Разбить монолитный компонент на понятные внутренние функции.
b) Анализ производительности: Понимать, какие внутренние функции являются "узкими местами".
c) Планирование рефакторинга: Видеть, какие функции могут быть выделены в отдельные микросервисы.
d) Детализация требований: Функции часто соответствуют нефункциональным требованиям (безопасность, логирование, кэширование).
e) Моделирование legacy-систем: Описать внутреннее устройство старой системы, у которой нет четкого API.
Сервис приложения (Application Service). Явно определённая внешне видимая единица функциональности, которую компонент предоставляет своим потребителям (другим приложениям или бизнес-процессам). Это ключевое связующее звено между бизнес-потребностями и технической реализацией.
Ключевое отличие от функции: Сервис — это "что предоставляется", функция — "как это реализовано внутри". Сервис — это "черный ящик", который делает что-то полезное. Потребителю не важно КАК это сделано (какой компонент, на каком языке), важно ЧТО делает сервис и КАК его вызвать.
Примеры: "Сервис проверки наличия товара", "Сервис регистрации нового клиента", "Сервис формирования выписки по счёту".
Ключевые отношения (магический треугольник):
a) Обслуживание бизнеса (Serves). Сервис обслуживает (serves) бизнес-процесс, бизнес-функцию или бизнес-сервис. Это его главная цель — поддерживать бизнес.
b) Реализация компонентом (Realized by). Сервис реализуется (is realized by) одним или несколькими компонентами приложения. Это показывает, кто выполняет работу.
c) Предоставление через интерфейс (Realized by Interface). Доступ к сервису осуществляется через интерфейс приложения (Application Interface).
Практические сценарии использования:
a) Проектирование API: Каждый endpoint API часто отображается как отдельный Application Service.
b) Создание сервисной модели предприятия (Service Landscape): Каталог всех сервисов, доступных в организации.
c) Анализ зависимостей: Какие бизнес-процессы зависят от каких сервисов? Что сломается при изменении сервиса?
d) Миграция и модернизация: При переходе с монолита на микросервисы сервисы остаются константой — меняется только их реализация (компоненты).
e) Спецификация для разработки: Service Contract — четкое ТЗ для команды разработки.
На диаграмме можно объяснить: какие сервисы поддерживают бизнес-процессы, взаимозависимости между сервисами, карту потребления сервисов бизнесом.
Взаимодействие приложения (Application Interaction). Единица коллективного поведения, описывающая паттерн взаимодействия между компонентами в рамках коллаборации. Показывает последовательность обмена данными или вызовами.
По существу, это "протокол взаимодействия" между компонентами. Показывает не ЧТО делают компоненты по отдельности, а КАК они работают ВМЕСТЕ для достижения общей цели. Не может существовать в одиночку, почти всегда находится внутри Application Collaboration. Это может быть, например, включение шаблона связи между компонентами. Компонент взаимодействия также может описывать внешне видимое поведение, необходимое для реализации служб приложения.
Пример: "Взаимодействие при оформлении заказа" между несколькими сервисами.
Ключевые отношения (связи):
a) Входит в коллаборацию (Composition или Assignment). Взаимодействие является частью коллаборации и описывает, как её участники работают вместе.
b) Связано с участниками (Assignment или Flow). Компоненты участвуют (assigned to) во взаимодействии.
c) Может использовать сервисы (Serving). Взаимодействие может использовать сервисы компонентов для выполнения своей логики.
d) Реализует поведение (Realization). Взаимодействие может реализовывать более высокоуровневое поведение.
Взаимодействие можно детализировать с помощью: последовательности вызовов (обычно показывается на отдельной диаграмме), обмена событиями (Application Event), потоков данных (Flow отношений)
Типовые сценарии использования:
a) Синхронное взаимодействие (запрос-ответ)
b) Асинхронное взаимодействие (события)
c) Длительные транзакции (Saga Pattern)
d) Синхронизация данных
Элемент позволяет "заглянуть внутрь" коллаборации и понять, КАК именно компоненты достигают результата вместе, что критически важно для проектирования отказоустойчивых, масштабируемых и сопровождаемых систем.
Процесс приложения (Application Process). Последовательность действий приложения, которая приводит к определённому результату. Может быть потоком управления или оркестрацией сервисов. Имеет значение для бизнеса на уровне приложений.
По существу - это "рецепт" выполнения работы на уровне приложений. Он описывает КАК приложение выполняет задачу шаг за шагом. Имеет начало, последовательность шагов и конец. Всегда производит значимый результат. Может содержать ветвления, циклы, параллельное выполнение.
Примеры: "Обработка платежа", "Синхронизация данных с внешней системой", "Пакетная обработка начислений".
Ключевые отношения (связи):
a) Состоит из функций (Composition или Aggregation). Процесс включает в себя функции приложения как свои шаги.
b) Реализуется компонентом (Assignment).Процесс назначается компоненту приложения, который его выполняет.
c) Использует сервисы (Serving). Процесс может использовать другие сервисы приложений.
d) Запускается событиями (Triggering). Процесс может запускаться событиями.
e) Порождает события (Flow). Процесс может создавать события как результат.
Типовые сценарии использования в моделях:
a) Оркестрация сервисов (Service Orchestration).
b) Пакетная обработка (Batch Processing)
c) Обработка событий (Event Processing)
Системное событие (Application Event). Состояние или изменение состояния в приложении (или его окружении), которое инициирует, запускает (triggers) какое-либо поведение или является его результатом (outcome)
Это пассивный элемент поведения — оно само ничего не "делает", а лишь фиксирует факт. Позволяет моделировать асинхронные, событийно-ориентированных (event-driven) взаимодействия между компонентами приложений.
Примеры: "Запрос на кредит получен", "Платеж подтвержден", "Ошибка влидации".
Типовые сценарии использования в моделях:
a) Оркестрация сервисов (Choreography): Показ, как несколько независимых сервисов координируются через обмен событиями (без центрального оркестратора).
b) Обработка ошибок и исключений: Моделирование реакций системы на сбои (Событие: "Таймаут соединения" → Процесс: "Повторная попытка").
c) Интеграция систем через шину событий (Event Bus): Показ, как компоненты публикуют и подписываются на события, не зная друг о друге.
d) Моделирование жизненных циклов: Последовательность событий, отражающих этапы жизни сущности (например, заявки: Создана → На проверке → Одобрена → Исполнена).
3) Пассивные структурные элементы (Application Passive Structure Elements)
Представляют данные или информацию, которыми манипулируют активные элементы.
Объект данных (Data Object). Фундаментальный элемент для моделирования информационной структуры на уровне приложений. Элемент данных, поддающийся идентификации, к которому имеет доступ и которым может манипулировать функция или процесс приложения (например, создавать, читать, изменять, удалять).
Данные должны быть представлены, как автономный кусок информации с четким смыслом для бизнеса, а не только с точки зрения уровня приложения. Типичные примеры объектов данных – это: запись о клиенте, клиентская база данных или страховой случай.
Примеры: Форма заказа (JSON/XML), счёт-фактура, запрос на кредит, запись таблицы, сессия пользователя.
Типовые отношения (связи):
a) Доступ к данным (Access). Самое важное отношение. Компонент, функция или процесс приложения получают доступ к объекту данных.
b) Реализация/Специализация (Realization или Specialization). Реализация: Более конкретный объект данных реализует (реализует) более абстрактный бизнес-объект (Business Object).
c) Ассоциация (Association). Показывает логическую связь между объектами данных.
d) Агрегация/Композиция (Composition). Объект данных может состоять из других объектов данных.
Типовые сценарии использования в моделях:
a) Моделирование контрактов API: Data Object "Запрос на создание" и "Ответ" для REST-endpoint.
b) Описание форматов сообщений в интеграции: Точная спецификация, что передается между системами.
c) Отслеживание жизненного цикла информации: Как данные трансформируются в процессе (Черновик → Валидированный → Подтвержденный → Архивный).
d) Анализ воздействия изменений: Если меняется структура Data Object "Счет", видно, какие функции/процессы его используют.
Основные возможности использования:
a) Делает информационные потоки явными.
b) Определяет контракты и форматы для взаимодействия компонентов.
c) Выявляет зависимости данных и потенциальные точки проблем при изменениях.
d) Создает полную картину того, как данные движутся и трансформируются в ИТ-ландшафте.
Диаграммы потоков данных позволяют акцентировать внимание на объектах данных, обозначить асинхронные потоки через шину событий, определить роли каждого компонента в обработке данных.
Формальное описание элементов, отношений и правил их использования на уровне приложений можно представить в виде метамодели.
Рассмотрим примеры, чтобы показать, как уровень приложений связан с другими уровнями и как его элементы работают вместе:
С бизнес-уровнем: Сервис приложения обслуживает Бизнес-процесс или Бизнес-сервис (отношение serving).
С технологическим уровнем: Компонент приложения разворачивается на Артефакте (например, JAR-файл, контейнер Docker) или Узле (сервере) (отношение assignment).
Внутри уровня приложений:
Компонент реализует (реализация) Сервис.
Компонент состоит из Функций (агрегация/композиция).
Функция использует (доступ) Объект данных.
Компонент предоставляет и требует Интерфейсы приложения.
Через Интерфейсы Компоненты взаимодействуют между собой.
Используя эти элементы, вы можете смоделировать архитектуру приложений, от монолитных систем до современных микросервисных ландшафтов, четко показав, как программное обеспечение поддерживает бизнес.