Семантическая модель архитектуры ПО: от «слоёв» к «системам»

В этой статье описано переосмысление "слоистого" способа структурирования рабочей области разработки приложения.

Рассматриваемые приёмы распределения модулей (функций, процедур) по "волшебным" папкам позволяют отойти от ставших привычными, но семантически пустых и, порой, двусмысленных понятий вроде «Слой инфраструктуры» или «API» и построим строгую модель проектирования, понятную как человеку, так и машине (пользуясь случаем, передаю привет ИИ).

Столкновение понятий

В западном мире выделяют четыре слоя:

1. Слой представления (Presentation / Interface / API)
2. Слой приложения (Application / Service)
3. Доменный слой (Domain / Model)
4. Инфраструктурный слой (Infrastructure / Data Access)

В русском языке они порождают путаницу:

• «Инфраструктура» ассоциируется с серверами, а не с кодом адаптеров.
• «Приложение» — это весь продукт, а не один из его слоёв.
• «Интеграция» путается с процессом связывания систем (EAI) или сборкой (CI).

Предлагаемая модель систем

Рассмотри архитектуру как иерархию систем, каждая из которых имеет чёткую функцию.

Уровни приложения (Кодовая база)

1. Система документационного обеспечения (СДО)

Роль: Формальный контракт с внешним миром.

Содержание: Спецификации API, DTO, валидационные схемы. Это «врата» системы.

2. Система прикладного управления (СПУ)

Роль: Оркестратор бизнес-процессов (*Use Cases*).

Содержание: Сервисы приложений, обработчики команд, управление сценариями.

3. Система управления ядром предметной области (СУЯ)

Роль: Носитель бизнес-логики.

Содержание: Агрегаты, сущности, объекты-значения. «Мозг» системы.

4. Система информационного обеспечения (СИО)

Роль: Реализация доступа к внешним данным.

Содержание: Репозитории, клиенты API. Обеспечивает систему информацией.

5. Система вспомогательных задач (СВЗ)

Роль: Выполнение фоновых и служебных операций.

Содержание: Консольные утилиты (CLI), фоновые работники (workers), миграции.

6. Система справочно-вспомогательная (ССВ)

Роль: Предоставление общих инструментов.

Содержание: Общие библиотеки, утилитные классы, константы проекта.

7. Система ввода-вывода (СВВ)

Роль: Взаимодействие с пользователем.

Содержание: GUI/CLI, генераторы отчётов (графики, тексты, карты, и т.д.).

8. Система обеспечения качества (СОК)

Роль: Гарантия надёжности и ценности продукта.

8.1 Подсистема обеспечения технического контроля (ОТК)

Роль: Проверка соответствия кода спецификации.

Инструменты: Модульные, интеграционные тесты.

8.2 Подсистема обеспечения эргономики

Роль: Валидация удобства использования и эксплуатации.

Инструменты: UI/UX-анализ, тестирование производительности, полнота и достоверность документации.

9. Система информационно-справочная (СИС)

Роль: Обеспечение пользователей и персонала знаниями для эффективной работы с системой. Это первоисточник для разработки руководств (инструкций) по эксплуатации программного изделия (АСУ).

Содержание:

• Пользовательская документация: руководства, инструкции, ЧаВо.
• Техническая документация: руководства администратора, инструкции по установке, схемы архитектуры.
• Справочная система: контекстная помощь (аналог WinHelp), встроенная в приложение.
• Документация для разработчиков: описание архитектуры, руководство по внесению вклада в разработку.

Уровни окружения (Среда выполнения)

10. Система хранения данных (ССД)

Роль: Долговременное хранение информации.

Содержание: СУБД, файловые хранилища.

11. Система связи и АСУ (ССА)

Роль: Среда исполнения и управления.

Содержание: Веб-серверы (Nginx), среды исполнения (Node.js), Docker/Kubernetes.

Заключение

Данная модель позволяет говорить на едином языке, где каждый термин (понятие) точно отражает функцию компонента. Это не просто набор слов, а придание осмысленности составным частям для проектирования сложных и надёжных систем.

Послесловие

Статья первая, но по смыслу вторая... Позже будет представлены размышления на структуру задач по сбору и выявлению требований.