Архитектура ИТ‑решений. Часть 7. Графический язык моделирования ArchiMate. Уровень приложений (продолжение)
---
7.2.3. Элементы уровня приложений (Application Layer)
Уровень приложений в ArchiMate описывает программные компоненты, их поведение, предоставляемые сервисы и обрабатываемые данные. Именно здесь моделируется логика прикладных систем, которая поддерживает бизнес‑процессы и связывает их с технической инфраструктурой. По сути, это архитектурный слой‑«мост» между бизнесом и «железом».
Метамодель ArchiMate для уровня приложений опирается на три крупные группы элементов:
1. Активные структурные элементы (Application Internal Active Structure Elements) – то, что «делает работу» (компоненты, модули, подсистемы).
2. Элементы поведения (Application Behavior Elements) – то, что именно выполняется (функции, процессы, сервисы).
3. Пассивные структурные элементы (Application Passive Structure Elements) – то, над чем работают (данные, объекты данных).
Ниже разберём ключевые элементы этого уровня и правила их использования.
---
Активные структурные элементы уровня приложений
Компонент приложения (Application Component)
Компонент приложения – это самостоятельная, логически цельная часть прикладной системы, которую можно отдельно разрабатывать, тестировать, внедрять и при необходимости заменять. Это основной и один из самых употребимых элементов при описании структуры приложений в ArchiMate.
Компонент приложения реализует одну или несколько функций или сервисов приложения, скрывая внутреннюю реализацию и предоставляя доступ к своей функциональности строго через набор интерфейсов.
Примеры компонентов:
- Система CRM;
- Модуль расчёта заработной платы;
- Веб‑сервис аутентификации;
- Микросервис «Корзина покупок».
Основные характеристики компонента
1. Модульность (самостоятельность)
Компонент представляет собой единицу, которую можно относительно независимо:
- разрабатывать,
- обновлять,
- масштабировать,
- заменять,
- разворачивать.
Важно понимать, что в реальных системах полная независимость редка, но архитектурная цель – минимизировать зависимости и сделать компонент максимально автономным.
2. Инкапсуляция
Внутренние детали реализации скрыты:
- внешний мир не знает о том, на каком языке написан компонент,
- не интересуется его внутренней структурой,
- не зависит от конкретной реализации внутренних классов, таблиц, модулей.
Коммуникация с компонентом разрешена только через формально описанные интерфейсы. Это уменьшает связность и облегчает модернизацию и рефакторинг.
3. Функциональная целостность
Компонент должен реализовывать логически связанный набор функций. Его название, как правило, выражается существительным и описывает предназначение:
- «Платёжный шлюз»,
- «Сервис уведомлений»,
- «Управление заказами»,
а не действие вида «Обработать платеж» или «Отправить уведомление». Это облегчает понимание модели и делает границы ответственности компонента более очевидными.
4. Гибкость детализации
Компонент может быть декомпозирован на подкомпоненты. Уровень детализации выбирает архитектор в зависимости от:
- цели модели (концептуальный, логический, физический уровень),
- аудитории (менеджмент, архитекторы, разработчики),
- задачи (описание ландшафта, проект системы, анализ влияний и т.д.).
В одной и той же организации можно встретить несколько уровней моделей: на верхнем уровне – крупные системы, на нижних – микросервисы и модули.
---
Связи компонента приложения с другими элементами
В ArchiMate важен не только сам элемент, но и то, как он взаимодействует с остальными. Для компонента приложения характерны несколько групп отношений.
I. Связи с элементами поведения (что делает компонент)
- Realization (Реализация)
Компонент реализует (realizes) один или несколько сервисов приложения.
Например: «Компонент "Платёжный шлюз" реализует сервис "Обработка платежей"».
- Assignment / Composition (Назначение / Состав)
Компонент может:
- назначаться (assigned to) функциям или процессам,
- состоять (composition) из нескольких функций или процессов, если нужно показать внутреннюю организацию поведения.
Таким образом, поведение (функции, процессы, сервисы) «привязано» к компоненту, который его исполняет.
II. Связи со структурными элементами (как устроен и как взаимодействует)
- Assignment с интерфейсами
Компонент предоставляет и/или использует интерфейсы приложений. Интерфейс при этом назначается (assigned to) компоненту‑владельцу.
- Composition / Aggregation с другими компонентами
Компонент может:
- включать в себя другие компоненты как составные части (composition),
- агрегировать связанные, но более слабо связанные модули (aggregation).
Так можно показать, например, что «Система CRM» включает «Модуль управления клиентами», «Модуль маркетинга», «Модуль аналитики».
III. Связи с другими уровнями (бизнес и технология)
- Serving с бизнес‑уровнем
Компонент приложения может обслуживать (serves) бизнес‑процессы или бизнес‑функции.
Здесь фиксируется, какая прикладная система поддерживает какую часть бизнеса.
- Realization / Assignment с технологическим уровнем
Компонент может:
- быть реализован технологическими объектами (серверы приложений, контейнеры, виртуальные машины),
- быть назначен на конкретные узлы инфраструктуры, платформы, базы данных и т.п.
Это связывает логическую модель приложений с физической архитектурой.
---
Интерфейс приложения (Application Interface)
Интерфейс приложения – это точка доступа к функциональности компонента. Именно через него другие компоненты, системы или бизнес‑акторы взаимодействуют с приложением. Условно это «фасад» компонента, через который внешний мир получает доступ к его возможностям.
Интерфейс может использоваться:
- внутри одного приложения (между модулями),
- между разными приложениями,
- между приложением и внешними системами,
- между бизнес‑пользователем и приложением (GUI).
Обычно интерфейс называют по типу данных или по сути взаимодействия, например:
- «Интерфейс транзакций»,
- «Интерфейс заказов»,
- «Интерфейс обмена клиентскими данными».
Частая ошибка – путать интерфейс и сервис. В ArchiMate это разные понятия.
Сервис vs Интерфейс: принципиальное различие
- Сервис приложения (Application Service) – это что делается:
логическая функциональность, предоставляемая приложением и несущая ценность для потребителя.
Пример: «Проверка платёжеспособности клиента», «Регистрация заказа».
- Интерфейс приложения (Application Interface) – это как получить доступ к сервису:
технический контракт, протокол, формат взаимодействия.
Пример: REST API, SOAP‑веб‑сервис, GUI, библиотека SDK, очередь сообщений.
Один и тот же сервис может быть доступен через разные интерфейсы:
- для внутренних систем – через REST API,
- для партнёров – через защищённый веб‑сервис,
- для операторов call‑центра – через графический интерфейс.
---
Типовые связи интерфейса приложения
Интерфейс связывается с несколькими типами элементов.
1. Interface – Component (Assignment)
Главная связь: интерфейс назначается компоненту, который его предоставляет.
Компонент является владельцем интерфейса и отвечает за его реализацию и поддержку.
2. Interface – Service (Realization)
Интерфейс реализует один или несколько сервисов приложения.
Через этот интерфейс потребители получают доступ к соответствующим сервисам.
Пример:
- «Интерфейс "OrderAPI" реализует сервис "Регистрация заказа" и "Просмотр статуса заказа"».
3. Interface – Consumer (Serving / Flow)
Другой компонент приложения, внешний актор или система использует (обслуживается через) этот интерфейс. В моделях это отражается как:
- отношение Serving – интерфейс обслуживает потребителя,
- либо Flow – через интерфейс проходит обмен данными.
Так фиксируется зависимость: если интерфейс изменится, может потребоваться доработка всех потребителей.
---
Пример цепочки связей: от бизнеса до компонента
Для понимания общей картины полезно проследить типовую связку элементов от бизнес‑уровня до уровня приложений:
1. Бизнес‑процесс
У бизнеса есть некая потребность: бизнес‑процесс требует выполнения определённой задачи
– например, «Оформление заказа».
2. Сервис приложения поддерживает бизнес
На уровне приложений моделируется сервис, который обслуживает (serves) этот бизнес‑процесс,
например, «Сервис "Регистрация заказа" обслуживает бизнес‑процесс "Оформление заказа"».
3. Сервис реализуется компонентом
Далее связываем сервис с компонентом:
«Компонент "Система управления заказами" реализует сервис "Регистрация заказа"».
4. Компонент предоставляет интерфейс
Компоненту назначается интерфейс:
«Интерфейс "OrderAPI" назначен компоненту "Система управления заказами"».
5. Интерфейс реализует сервис
Через этот интерфейс становятся доступны сервисы:
«Интерфейс "OrderAPI" реализует сервис "Регистрация заказа"».
6. Другие компоненты используют интерфейс
Другой компонент (например, «Интернет‑витрина») использует этот интерфейс для работы с заказами.
В модели это отражается как то, что компонент‑потребитель обращается к интерфейсу и через него – к сервису.
Такая связка позволяет проследить линию ответственности:
от бизнес‑задачи → через сервис → к компоненту → к интерфейсу → к потребителям.
---
Зачем так детализировать уровень приложений
Разделение на компоненты, сервисы и интерфейсы может показаться избыточным, но на практике оно даёт несколько ключевых преимуществ:
1. Прозрачная карта приложений
Появляется наглядная схема: какие системы за что отвечают и какие бизнес‑процессы поддерживают. Это облегчает обсуждение с бизнесом и ИТ, планирование развития и бюджетирование.
2. Управление зависимостями
Можно видеть, какие компоненты завязаны на какие интерфейсы и сервисы. Это критично при изменениях: обновление или замена одного компонента требует оценки влияния на потребителей его интерфейсов.
3. Поддержка модульной и микросервисной архитектуры
ArchiMate хорошо ложится на современные подходы: микросервисы в моделях выглядят как небольшие компоненты с узкими, чётко определёнными интерфейсами и сервисами.
4. Удобство для интеграции
Явное выделение интерфейсов помогает систематизировать интеграции:
- какие приложения интегрированы,
- через какие интерфейсы,
- по каким протоколам,
- какие сервисы доступны внешним системам.
5. Упрощение коммуникации между участниками проекта
Архитектор, аналитик, разработчик и бизнес‑представитель, глядя на одну модель, видят каждый своё:
- бизнес – какие процессы поддерживаются,
- архитектор – структуру приложений и связи,
- разработчик – какие интерфейсы нужно реализовать.
---
Практические рекомендации по моделированию компонентов и интерфейсов
1. Не дробите до уровня классов и таблиц, если цель – корпоративная архитектура. Декомпозиция до очень мелких элементов перегружает модель и ухудшает читаемость.
2. Выбирайте уровень детализации под задачу:
- для обзора ландшафта – крупные системы и несколько ключевых интерфейсов;
- для проектирования интеграции – детальное описание интерфейсов и сервисов, задействованных в конкретном сценарии.
3. Следите за именами:
- компоненты – существительные, отражающие область ответственности;
- сервисы – тоже существительные, но с акцентом на предоставляемую возможность;
- интерфейсы – по типу взаимодействия/данных (например, «API заказов», «GUI оператора»).
4. Фиксируйте критичные зависимости:
- зависимости между ключевыми бизнес‑процессами и сервисами;
- зависимости компонентов от внешних интерфейсов;
- использование устаревших интерфейсов, которые планируется заменить.
5. Используйте связки "бизнес–сервис–компонент–интерфейс" как стандарт
Это создаёт единый подход к моделированию и облегчает навигацию по архитектурным артефактам.
---
Связь уровня приложений с другими слоями архитектуры
Уровень приложений не существует сам по себе. Он тесно интегрирован:
- С бизнес‑архитектурой
Здесь мы видим, какие процессы, функции и роли использует каждая прикладная система, какой сервис какую бизнес‑ценность даёт.
- С информационной архитектурой
Пассивные элементы приложения (данные, объекты данных) связываются с корпоративными информационными сущностями. Так видно, какие системы владеют какими данными и где хранятся мастер‑данные.
- С технической архитектурой
Компоненты и интерфейсы опираются на инфраструктурные элементы: сервера приложений, СУБД, очереди сообщений, шины данных и т.д. Это важно для анализа производительности, надёжности и планирования мощностей.
---
Таким образом, элементы уровня приложений в ArchiMate – компоненты, интерфейсы, сервисы и связанные с ними объекты поведения и данных – позволяют формализованно, наглядно и однозначно описывать архитектуру прикладных решений. Грамотное использование этих элементов делает модель не просто картинкой, а рабочим инструментом для анализа, планирования и развития ИТ‑ландшафта организации.
