Прикладной и технологический слои

10 мин

На этой странице

1. Суть темы
2. Ключевые понятия
2.1. Элементы прикладного слоя
2.2. Элементы технологического слоя
2.3. Отношения: внутри слоя и между слоями
3. Как применяется в работе аналитика
3.1. Сквозной пример: интернет-магазин
3.2. Трассировка требований
3.3. Гранулярность Application Component
3.4. Viewpoints и инструменты
3.5. Практические рекомендации
4. Типовые ошибки и ограничения
Связи с другими разделами базы
Источники и дополнительные материалы
Книги и стандарты
Статьи и практические материалы

Прикладной и технологический слои в ArchiMate завершают цепочку «от мотивации до инфраструктуры»: если 06.03.02 Бизнес-слой описывает деятельность организации, а 06.03.01 Мотивационный слой — её стратегические причины, то прикладной слой показывает, какие системы автоматизируют бизнес, а технологический — на чём они работают. Для системного аналитика эти слои — язык трассировки от требований и бизнес-сервисов к компонентам, интерфейсам и узлам развёртывания. Правила межслойных связей (Serving, Realization, Assignment, Deployment) и viewpoints — в 06.03.04 Взаимосвязи и точки зрения (Viewpoints); здесь — элементы двух слоёв и корректное применение связей на практике.

1. Суть темы

Прикладной слой (Application Layer) моделирует программные системы: компоненты, сервисы, интерфейсы, данные и внутреннее поведение. Он абстрагируется от языка и фреймворка, но фиксирует логическую структуру автоматизации.

Технологический слой (Technology Layer) описывает инфраструктуру исполнения: узлы, устройства, системное ПО, артефакты, сети и технологические сервисы.

Оба слоя связаны с бизнес-слоем сверху (через Serving и Realization) и между собой снизу вверх (технология обслуживает приложения; артефакты реализуют компоненты). Ниже технологического слоя в полной модели ArchiMate 3.x есть слой внедрения и миграции (Implementation & Migration Layer) — там живут work packages, deliverables и roadmap; артефакт частично пересекается с этим слоём как результат поставки. Отдельный физический слой (Physical Layer) — оборудование и помещения — в полной спецификации идёт рядом с технологическим; в этой ветке базы знаний он не разбирается: для SA достаточно технологического слоя и deployment-view.

Граница с соседними статьями. Детали REST, Kafka, OpenAPI, ER-моделей, DevOps-процессов и классификации NFR — в соответствующих разделах базы (03.05.02 Синхронные протоколы (REST, gRPC, GraphQL), 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events), 03.03.01 ER-диаграммы (сущность-связь), 05.04 DevOps и непрерывная поставка — влияние на анализ). Здесь — ArchiMate-элементы и типы связей, чтобы на диаграмме в Archi или Enterprise Architect не перепутать Realization и Serving.

2. Ключевые понятия

2.1. Элементы прикладного слоя

Элемент	Роль	Примечание для SA
Application Component	Автономная заменяемая часть ПО	Гранулярность договаривается на проекте: система, продукт, микросервис или модуль — см. раздел 3.3
Application Service	Явно определённая функциональность «снаружи» компонента	«Сервис проверки кредитной истории»
Application Interface	Точка доступа к сервису	REST API, UI, файловый обмен — детали протокола в 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)
Application Function	Внутреннее поведение, сгруппированное по цели	Статичная capability внутри компонента
Application Process	Упорядоченная последовательность прикладных действий	Поток шагов с началом и концом
Application Event	Событие, запускающее или завершающее поведение	«Заказ оплачен», «Файл загружен» — источник для Triggering
Application Interaction	Коллективное поведение нескольких компонентов без внутренней декомпозиции	Интеграционные сценарии «система A и B обмениваются данными»
Application Collaboration	Объединение компонентов для совместной работы	Постоянная или временная группа
Data Object	Информационная единица прикладного слоя	Логическая сущность; трассируется к Business Object через Realization (06.03.02 Бизнес-слой); физическая детализация — в 03.03.02 Логическая и физическая модель данных

Function vs Process vs Collaboration vs Interaction. Function — «что умеет компонент» (стабильная группа логики). Process — «как выполняется поток» (последовательность с входом и выходом). Collaboration — именованная группа компонентов. Interaction — единое коллективное действие без пошаговой детализации.

На примере интернет-магазина: Application Process «Оформить заказ» живёт внутри компонента «Модуль заказов» (Assignment) и через Access работает с Data Object «Заказ». Application Interaction «Списать оплату» связывает «Модуль заказов» и COTS «Платёжный шлюз» — достаточно одного interaction на диаграмме кооперации, без пошагового BPMN внутри vendor-системы.

COTS / SaaS. Коробочный продукт или облачный сервис моделируйте как один Application Component с Application Interface «снаружи» (API поставщика, web-портал). Внутреннюю структуру vendor-системы не раскрывайте — это вне границ вашей архитектуры (02.01.04 Определение границ решения (Scope Modelling), 03.01.02 Моделирование контекста системы (Context Diagram)). Связь с вашими компонентами — через Serving или Flow на уровне интеграции (03.01.04 Интерфейсы и интеграционные взаимодействия).

Нотация. В ArchiMate 3.x компонент — прямоугольник прикладного слоя (часто с иконкой приложения); сервис — прямоугольник с «ушком» слева; интерфейс — круг или символ порта. Не путайте grouped notation с Composition.

2.2. Элементы технологического слоя

Элемент	Роль	Примечание для SA
Node	Вычислительный ресурс для размещения артефактов и системного ПО	VM, bare metal, PaaS, pod в кластере
Device	Физическое оборудование	Серверное шасси, СХД, сетевой коммутатор — когда важна физическая топология
System Software	ОС, СУБД, брокер, runtime	Отдельный элемент, назначаемый на Node (Assignment), а не «категория узла»
Technology Service	Инфраструктурная услуга для верхних слоёв	«Хранилище данных», «Маршрутизация сообщений»
Technology Interface	Точка подключения к технологическому сервису	Порт, endpoint, socket
Technology Function / Process / Interaction	Поведение инфраструктуры	Резервное копирование, балансировка, кластерный обмен
Artifact	Развёртываемый файл: jar, war, Docker-образ, SQL-скрипт	Мост между кодом и инфраструктурой
Network, Communication Path	Связность между узлами	Протоколы, пропускная способность

Device vs Node. Node — логический ресурс исполнения: достаточно для облака, Kubernetes, managed PaaS, когда физическое оборудование скрыто провайдером. Device — когда на сессии важны стойка, железо, отказоустойчивость на уровне оборудования или on-premise без абстракции. На одной модели не смешивайте: либо deployment-view через Node, либо infrastructure-view с Device и Communication Path между ними.

2.3. Отношения: внутри слоя и между слоями

Ниже — связи, которые SA чаще всего путает на прикладном и технологическом слоях. Derived relationships, полная матрица viewpoints и правила layered views — только в 06.03.04 Взаимосвязи и точки зрения (Viewpoints); здесь не дублируем.

ArchiMate различает Realization (конкретное реализует абстрактное), Serving (элемент предоставляет функциональность другому), Assignment (активная структура выполняет поведение или размещает артефакт), Access (поведение работает с пассивной структурой), Flow (передача между поведением), Triggering (событие запускает поведение), Deployment (связь Artifact ↔ Node через Assignment).

Отношение	Типичное направление	Когда применять
Realization	Application Component → Application Service; Artifact → Application Component; Data Object → Business Object	«Как реализовано» внутри слоя или снизу вверх по абстракции
Serving	Application Service → Business Process / Role; Technology Service → Application Component / Process	«Кто кого обслуживает» между слоями; главная межслойная связь
Assignment	Application Component → Application Function / Process; System Software → Node; Artifact → Node	Назначение поведения или размещение на узле
Access	Application Process → Data Object	Чтение/запись данных (с модификатором read/write)
Flow	Application Process → Application Process	Передача Data Object между шагами
Triggering	Application Event → Application Process	Событие запускает поведение
Composition / Aggregation	Компонент состоит из подкомпонентов; интерфейс — часть компонента	Декомпозиция системы (03.01.03 Декомпозиция системы на подсистемы и модули)

Критично для SA. Не сводите все связи к «реализации». Бизнес-процесс использует (Serving от прикладного сервиса к процессу) прикладной сервис; прикладной компонент реализует прикладной сервис. Технологический сервис обслуживает прикладной компонент — это Serving, не Realization и не прикладной Access к Data Object. Deployment — это Assignment артефакта на узел (или на системное ПО), а не синоним Realization.

Assignment vs Serving между слоями. Assignment связывает активную структуру с поведением внутри одного слоя (компонент → функция). Прикладной компонент не «назначается» на бизнес-процесс: связь бизнеса с приложением — Serving (сервис обслуживает процесс) или Triggering/Flow на viewpoint интеграции. Подробные правила и viewpoints — 06.03.04 Взаимосвязи и точки зрения (Viewpoints).

3. Как применяется в работе аналитика

3.1. Сквозной пример: интернет-магазин

Бизнес-процесс «Оформить заказ» реализует бизнес-сервис «Приём заказов». Его автоматизирует прикладной сервис OrderService: компонент «Модуль заказов» реализует этот сервис; интерфейс REST /orders — часть компонента (Composition). Docker-образ order-service:latest реализует компонент и развёрнут на узле Kubernetes через Docker Engine; PostgreSQL как System Software назначен на тот же узел и реализует технологический сервис «Хранилище данных», который обслуживает компонент «Модуль заказов».

На Application Usage viewpoint OrderService обслуживает (Serving) бизнес-процесс «Оформить заказ». Связь прикладного сервиса с бизнес-сервисом «Приём заказов» на одной диаграмме обычно не рисуют напрямую: она проходит через процесс (процесс реализует сервис; прикладной сервис обслуживает процесс). На service-oriented viewpoint допустимо Serving от Application Service к Business Service — выбор зависит от аудитории модели.

Serving от «Хранилища данных» к компоненту заказов — инфраструктурная capability СУБД, а не прикладной Access к сущности «Заказ». Доступ к Data Object «Заказ» моделируйте на прикладном слое: Application Process → Access → Data Object.

graph TD
    subgraph Business [Бизнес-слой]
        BP[Бизнес-процесс: Оформить заказ]
        BS[Бизнес-сервис: Приём заказов]
        BP -->|Realization| BS
    end

    subgraph Application [Прикладной слой]
        AS[Application Service: OrderService]
        AC[Application Component: Модуль заказов]
        AI[Application Interface: REST /orders]
        DO[Data Object: Заказ]
        AP[Application Process: Оформить заказ]
        AC -->|Realization| AS
        AC -->|Composition| AI
        AC -->|Assignment| AP
        AP -->|Access| DO
    end

    subgraph Technology [Технологический слой]
        Node[Node: Кластер Kubernetes]
        SS1[System Software: Docker Engine]
        SS2[System Software: PostgreSQL]
        A1[Artifact: order-service:latest]
        TS[Technology Service: Хранилище данных]
        SS1 -->|Assignment| Node
        SS2 -->|Assignment| Node
        A1 -->|Assignment| SS1
        A1 -->|Realization| AC
        SS2 -->|Realization| TS
    end

    AS -->|Serving| BP
    TS -->|Serving| AC

    style BP fill:#d5e8d4,stroke:#333
    style BS fill:#f8cecc,stroke:#333,stroke-dasharray: 5 5
    style AS fill:#f8cecc,stroke:#333,stroke-dasharray: 5 5
    style AC fill:#e1d5e7,stroke:#333
    style AI fill:#d0e0ff,stroke:#333
    style DO fill:#fff2cc,stroke:#333
    style AP fill:#e1d5e7,stroke:#333
    style Node fill:#f5f5f5,stroke:#333
    style SS1 fill:#ffe6cc,stroke:#333
    style SS2 fill:#ffe6cc,stroke:#333
    style A1 fill:#fff2cc,stroke:#333
    style TS fill:#f8cecc,stroke:#333,stroke-dasharray: 5 5

В инструментах ArchiMate стрелки Serving и Realization имеют стандартную нотацию; Mermaid здесь показывает логику направлений, а не точную графику спецификации.

3.2. Трассировка требований

На том же примере цепочка для матрицы трассировки (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки):

Уровень	Элемент	Связь с вышележащим
Мотивация (06.03.01 Мотивационный слой)	Requirement «Клиент оформляет заказ онлайн»	Influence / Realization → Outcome
Бизнес (06.03.02 Бизнес-слой)	Business Service «Приём заказов»	Realization ← Business Process
Бизнес	Business Object «Заказ»	Realization ← Data Object «Заказ»
Прикладной	Application Service OrderService	Serving → Business Process
Прикладной	Application Interface REST `/orders`	часть компонента (Composition); контракт в 10.01.04 Шаблон спецификации REST API
Технологический	Artifact + Node	Realization → Component; Assignment → Node

Изменение NFR по доступности (08.02 Нефункциональные требования (НФТ) — классификация и стандарты) затрагивает Technology Service и топологию узлов — это видно на технологическом слое, не смешивая с прикладной логикой.

3.3. Гранулярность Application Component

Один компонент на диаграмме = единица изменений в архитектурной модели: элемент с собственным жизненным циклом поставки, а не задача change control board. Договоритесь в команде о правиле:

Крупно: один компонент = продукт или система (подходит для roadmap и портфеля).
Средне: один компонент = deployable unit (микросервис, модуль с отдельным релизом).
Мелко: внутренние классы и пакеты — уже UML (06.01.01 Структурные диаграммы (Class, Object, Package)), не ArchiMate.

Критерий: если у элемента свой жизненный цикл поставки (отдельный artifact, отдельная команда) — выделяйте отдельный Application Component (03.01.03 Декомпозиция системы на подсистемы и модули).

3.4. Viewpoints и инструменты

Для прикладного и технологического слоёв чаще всего нужны Application Usage, Application Cooperation, Application Structure, Deployment и Infrastructure viewpoints — они задают, какие элементы и связи показывать на одной диаграмме. Полный каталог viewpoints, layered views и правила derived relationships — в 06.03.04 Взаимосвязи и точки зрения (Viewpoints); здесь не дублируем.

Моделируйте в 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io) или Archi. Для контейнеров и оркестрации контекст узлов/артефактов уточняйте по 07.08 Контейнеризация и оркестрация (Docker, Kubernetes). Альтернатива для прикладного и deployment-вида — 06.03.05 C4-модель (одна строка: C4 Container/Component частично пересекается с Application Component, но ArchiMate богаче межслойными связями).

3.5. Практические рекомендации

Стройте прикладной слой от бизнес-сервисов — каждый Application Service должен обслуживать (Serving) конкретный бизнес-процесс, роль или сервис.
Не смешивайте слои на одной view без viewpoint — API и интеграции — прикладной слой; конфигурация серверов и кластеров — технологический.
Связывайте код с развёртыванием через Artifact — образ или пакет из CI/CD (07.06 CICD и конвейеры — влияние на требования) реализует компонент и назначается на узел.
Документируйте Application Interface явно — протокол и формат данных; спецификация контракта — в 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf).
Для интеграций используйте Interaction или Collaboration — не рисуйте десять Flow между компонентами, если достаточно одного interaction и ссылки на 03.05.01 Виды интеграции (точка-точка, ESB, API-led).

4. Типовые ошибки и ограничения

Ошибка	Почему плохо	Как правильно
Стрелка Realization от сервиса к компоненту	Направление обратное метamodel	Component realizes Service
«Бизнес-сервис реализуется прикладным сервисом»	Смешение Serving и Realization	Application Service serves Business Process
Technology Service «реализует» Application Component	Неверный тип связи	Technology Service serves Application Component
Serving технологического сервиса трактуют как Access к Data Object	Разные слои и смысл	Access — Process → Data Object; Serving TS → Component — инфраструктура
System Software нарисован как Node	Теряется Assignment	System Software assigned to Node
Assignment компонента на бизнес-процесс	Assignment — внутри слоя	Serving от Application Service к процессу
Один компонент = и монолит, и каждый класс	Шум на диаграмме	Договорённость о гранулярности (раздел 3.3)
COTS-модуль с внутренней декомпозицией vendor	Вне scope	Один Component + внешний Interface
Подмена ArchiMate детальным BPMN/UML на той же view	Разный уровень абстракции	ArchiMate — скелет; детали — в 03.04.01 BPMN 2.0 - введение и основы или UML

ArchiMate не заменяет спецификацию API, ER-диаграмму или runbook инфраструктуры — он связывает их на архитектурном уровне. Не ожидайте исполняемости модели в Camunda или генерации кода из диаграммы.

Связи с другими разделами базы

06.03.01 Мотивационный слой — цели и требования, от которых трассируются сервисы
06.03.02 Бизнес-слой — процессы, сервисы и Business Object, которые обслуживает прикладной слой
06.03.04 Взаимосвязи и точки зрения (Viewpoints) — межслойные связи, viewpoints и derived relationships
06.03.05 C4-модель — альтернативная нотация прикладного и deployment-вида
03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая) — место слоёв в видах архитектуры
03.01.02 Моделирование контекста системы (Context Diagram) — граница COTS/SaaS и внешних систем
03.01.03 Декомпозиция системы на подсистемы и модули — правила разбиения на Application Component
03.01.04 Интерфейсы и интеграционные взаимодействия — прикладные интерфейсы и интеграционные паттерны
03.05.01 Виды интеграции (точка-точка, ESB, API-led) — Application Interaction и сотрудничество компонентов
03.05.02 Синхронные протоколы (REST, gRPC, GraphQL) — протоколы прикладных интерфейсов
03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) — контракты к Application Interface
03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events) — асинхронные потоки между компонентами
03.03.01 ER-диаграммы (сущность-связь) — детализация Data Object
07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io) — практика моделирования ArchiMate
07.08 Контейнеризация и оркестрация (Docker, Kubernetes) — узлы, артефакты и system software
08.02 Нефункциональные требования (НФТ) — классификация и стандарты — мотивация технологического слоя
10.01.04 Шаблон спецификации REST API — спецификация прикладного интерфейса
10.01.13 Шаблон архитектурного решения (ADR) — фиксация решений по компонентам и развёртыванию

Источники и дополнительные материалы

Книги и стандарты

The Open Group. ArchiMate 3.1 Specification — главы 9 (Application Layer) и 10 (Technology Layer); раздел 5 (Relationships). Официальная спецификация; полный текст может требовать регистрации или покупки на The Open Group. Обзор стандарта: https://www.opengroup.org/open-group-archimate-modeling-language
The Open Group. ArchiMate 3.1 Specification (PDF) — открытая копия спецификации: https://www.opengroup.org/sites/default/files/docs/downloads/n190p_5.pdf
Marc Lankhorst et al. «ArchiMate 3.0.1: A Pocket Guide» — краткое описание элементов прикладного и технологического слоёв.
Gerben Wierda. «Mastering ArchiMate Edition III» — разбор Realization, Serving и deployment-цепочек на примерах.

Статьи и практические материалы

The Open Group. ArchiMate 101: A Practical Introduction — введение в Business, Application и Technology layers: https://archimate-community.pages.opengroup.org/workgroups/archimate-101/
Archi — инструмент моделирования ArchiMate — палитры Application и Technology layers: https://www.archimatetool.com/