Уровни архитектуры ИС
Информационная система слишком сложна, чтобы описывать её одним представлением. Поэтому полезно выделять несколько уровней архитектуры. Каждый уровень показывает свой взгляд на ИС и помогает не смешивать разные типы решений.
Функциональная архитектура описывает ИС с точки зрения функциональных подсистем и их взаимодействия. На этом уровне удобно обсуждать, какие функции нужны пользователям, какие крупные блоки есть в системе и какой результат они дают. Этот уровень понятен стейкхолдерам и помогает показывать систему как набор полезных возможностей.
Информационная архитектура показывает, с какими информационными объектами работает система: заявки, документы, заказы, платежи, справочники, события, отчёты, состояния. Здесь важны термины предметной области, связи между объектами и правила, которые ограничивают допустимые изменения.
Программная архитектура описывает внутреннее устройство программной части: слои, модули, классы, интерфейсы, компоненты и зависимости. На этом уровне появляются контроллеры, сервисы приложения, предметные модели, репозитории, адаптеры, DTO и другие технические элементы.
Системная архитектура описывает размещение ИС как программно-аппаратного комплекса: клиентские устройства, серверы, сети, внешние устройства, среды выполнения, коммуникационные каналы. Важно не путать этот уровень со слоистой программной архитектурой: слои говорят об организации кода, системная архитектура — о размещении и среде.
Архитектура данных уточняет, как данные хранятся, передаются и поддерживают целостность. Она связана с концептуальной моделью, но не совпадает с ней: один предметный объект может храниться в нескольких структурах, а одна структура хранения может обслуживать несколько технических представлений.
Уровни удобно сравнивать по вопросам:
| Уровень | Основной вопрос | Типовые артефакты | Типичная ошибка |
|---|---|---|---|
| Функциональный | что система делает? | требования, цели, варианты использования | описывать экраны вместо целей |
| Информационный | с какими понятиями работает система? | словарь, концептуальная модель | превращать все существительные в классы |
| Программный | как организовано ПО? | классы, пакеты, компоненты | смешивать предметные объекты с DTO и контроллерами |
| Системный | где и в какой среде это работает? | схема размещения, узлы, среды | рисовать серверы без связи с требованиями |
| Данные | как информация хранится и передаётся? | структуры хранения, ограничения, форматы обмена | считать класс и таблицу одним и тем же |
Разделение уровней помогает удерживать модель в порядке. Пользовательская цель не должна смешиваться с таблицей базы данных, бизнес-правило — с конкретным методом проверки, сервер — с программным компонентом, а предметный объект — с DTO или ORM-сущностью.
При этом уровни не являются жёсткой последовательностью, которую нельзя нарушать. Новое нефункциональное требование может заставить пересмотреть размещение. Новое бизнес-правило может изменить предметную модель. Ограничение внешней системы может повлиять на процесс. Но даже при итерациях полезно понимать, на каком уровне сейчас принимается решение.