Уровни архитектуры ИС

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

Уровни архитектуры

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

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

Программная архитектура описывает внутреннее устройство программной части: слои, модули, классы, интерфейсы, компоненты и зависимости. На этом уровне появляются контроллеры, сервисы приложения, предметные модели, репозитории, адаптеры, DTO и другие технические элементы.

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

Архитектура данных уточняет, как данные хранятся, передаются и поддерживают целостность. Она связана с концептуальной моделью, но не совпадает с ней: один предметный объект может храниться в нескольких структурах, а одна структура хранения может обслуживать несколько технических представлений.

Как не смешивать уровни

Уровни удобно сравнивать по вопросам:

Уровень	Основной вопрос	Типовые артефакты	Типичная ошибка
Функциональный	что система делает?	требования, цели, варианты использования	описывать экраны вместо целей
Информационный	с какими понятиями работает система?	словарь, концептуальная модель	превращать все существительные в классы
Программный	как организовано ПО?	классы, пакеты, компоненты	смешивать предметные объекты с DTO и контроллерами
Системный	где и в какой среде это работает?	схема размещения, узлы, среды	рисовать серверы без связи с требованиями
Данные	как информация хранится и передаётся?	структуры хранения, ограничения, форматы обмена	считать класс и таблицу одним и тем же

Разделение уровней помогает удерживать модель в порядке. Пользовательская цель не должна смешиваться с таблицей базы данных, бизнес-правило — с конкретным методом проверки, сервер — с программным компонентом, а предметный объект — с DTO или ORM-сущностью.

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

UML-представления уровней

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

C4 не образует ещё один уровень архитектуры: контекст системы и контейнеры собирают элементы нескольких уровней в карту для выбранной аудитории.