Декомпозиция — базовый приём системного анализа между контекстом системы и проектированием интерфейсов. Аналитик разбивает систему на подсистемы и модули, чтобы управлять сложностью, сгруппировать требования и локализовать изменения. Ключевой вопрос, который закрывает эта тема: где провести границы так, чтобы структура была понятна бизнесу, командам и интеграциям — и при этом не смешивать логический разрез с единицами развёртывания.

1. Суть темы

Декомпозиция — разделение системы на более мелкие, логически обособленные части, каждая из которых решает ограниченный круг задач. В цепочке 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая) она относится к системной архитектуре: после контекстной диаграммы и до детализации интерфейсов. Для системного аналитика это не абстрактное упражнение: структура напрямую влияет на группировку требований, распределение работ между командами, точки интеграции и формулировку сценариев.

Грамотный разрез даёт:

  • Управление сложностью — система становится познаваемой на уровне, с которым можно работать в спецификации и на ревью.
  • Параллельную разработку — независимые команды ведут разные подсистемы или модули.
  • Локализацию изменений — новые требования и дефекты затрагивают ограниченный набор частей.
  • Основу для трассировки — каждый модуль или подсистема получает связанный блок требований (см. 02.03.04 Трассировка требований (концепция) и 10.01.15 Шаблон матрицы трассировки).

Логическая и физическая декомпозиция

На практике декомпозицию нужно вести в двух измерениях — они связаны, но не совпадают один к одному:

ИзмерениеЧто описываетАртефакты аналитикаПример
ЛогическаяОтветственность, границы предметной области, интерфейсы между частямиДиаграмма пакетов, DFD, capability map, C4 ComponentПодсистема «Каталог», модуль «Поиск»
Физическая (развёртывание)Единицы сборки, развёртывания, масштабированияC4 Container, deployment diagram, диаграмма компонентов UMLОдин модуль «Платежи» = один JAR в монолите; три модуля каталога = один микросервис catalog-service

Правило для аналитика: сначала фиксируйте логический разрез (что за что отвечает и через какие интерфейсы общается), затем отдельно решайте, как логические модули отображаются на контейнеры, процессы и команды. В 06.03.05 C4-модель Container — единица развёртывания (часто сервис или приложение), а не синоним подсистемы; логическая подсистема может отображаться на один или несколько контейнеров, а несколько модулей — жить в одном контейнере. Чек-лист «независимое тестирование» и «своя команда» относится к целевому физическому или организационному контексту — не к каждой строке логической диаграммы.

Подсистема в продукте и модуль в backlog команды — разные проекции одной структуры; их согласование с границами релиза описано в 02.01.04 Определение границ решения (Scope Modelling).

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

2.1. Иерархия: система → подсистема → модуль → компонент

УровеньОпределениеУровень абстракции (логический)Отображение на развёртывание (C4)Пример (интернет-магазин)
Система (System)Целостная совокупность элементов, решающая бизнес-задачуКонтекстC4 ContextИнтернет-магазин
Подсистема (Subsystem)Крупная функционально завершённая часть; значимая бизнес-способность (capability)Крупный логический пакет, capability mapОдин или несколько Container — отдельный шаг маппинга«Каталог товаров», «Обработка заказов», «Платёжный шлюз»
Модуль (Module)Логически связанная группа с одной атомарной ответственностью и стабильным интерфейсомUML Package, C4 ComponentМодули упаковываются в Container; не обязаны совпадать 1:1В «Каталоге»: «Поиск», «Фильтрация», «Карточка товара»
Компонент (Component)Заменяемая единица реализации внутри модуля, предоставляющая сервисы через интерфейсыUML Component, C4 Component (детализация)Не обязательно deployable unit«Адаптер Elasticsearch», «Компонент галереи»

Когда рисовать «модуль», а когда «компонент»: на архитектурных диаграммах аналитик оперирует модулями — единицами ответственности и контрактов. Компонент на диаграмме компонентов UML — заменяемая часть (класс, библиотека, адаптер, UI-виджет), а не обязательно единица развёртывания. Микросервис — физическая единица; логически он может соответствовать одной подсистеме, одному модулю или ошибочно — нескольким связанным модулям (см. 03.06.01 Архитектурные паттерны распределённых систем).

В небольших проектах «модуль» и «компонент» иногда используют как синонимы; в архитектурно значимых решениях различие фиксируйте в глоссарии.

2.2. Связность и связанность

Связность (Cohesion) — насколько элементы внутри модуля сфокусированы на одной задаче. Цель — высокая связность, предпочтительно функциональная или последовательная (классификация Myers/Constantine; подробнее — 01.06 Принципы и паттерны проектирования решений).

Связанность (Coupling) — степень взаимозависимости между модулями. Цель — низкая связанность; обмен через интерфейсы и простые данные, а не через общее внутреннее состояние.

Принцип проектирования: Low Coupling, High Cohesion.

2.3. Сопутствующие принципы

  • Единственная ответственность (SRP) — у подсистемы, модуля или компонента одна понятная причина для изменения, видимая бизнесу и команде.
  • Сокрытие информации (Information Hiding) — реализация за стабильным интерфейсом; потребители не зависят от внутренних деталей.
  • Разделение интерфейсов (ISP) — узкие контракты вместо «толстого» API; детали проектирования интерфейсов — в 03.01.04 Интерфейсы и интеграционные взаимодействия.

2.4. Слои внутри модуля vs «технические» модули

Слоистая декомпозиция (UI → сервисы → репозитории) — нормальная внутренняя структура бизнес-модуля: горизонтальные слои не конкурируют с доменными границами, а организуют код внутри одной ответственности.

Ошибка — выносить сквозные технические задачи в отдельные равноправные «бизнес-модули» без предметного смысла: «Валидация», «Логирование», «Конвертация». Такие задачи остаются внутри доменного модуля или оформляются как инфраструктурные библиотеки / cross-cutting concerns, а не как самостоятельные подсистемы наряду с «Заказами» и «Каталогом».

2.5. Владение данными и границы сущностей

Логический разрез «по функциям» без правил данных порождает распределённый монолит на этапе интеграции. Для каждой сущности или агрегата зафиксируйте единственного владельца (owning module / bounded context) и режим доступа соседей:

РежимСмыслКогда допустимПример
Owner (write)Модуль создаёт, изменяет и удаляет данные; остальные обращаются через его API или событияОсновной режим для доменных сущностейМодуль «Оформление» владеет Order; «Каталог» — Product
Read-only replicaЛокальная копия для отчётов, поиска, кэша; источник истины — у владельцаПроизводительность, CQRS, eventual consistency«Поиск» читает denormalized индекс товаров из событий «Каталога»
Shared referenceОбщий справочник без доменной логики; изменения редки и согласованыСтатусные коды, валюты, единицы измеренияСправочник «Страны» — отдельный модуль или shared library с явным владельцем-куратором

Артефакт декомпозиции: таблица «сущность → владелец → способ доступа» на основе 03.03.01 ER-диаграммы (сущность-связь); при сложной предметной области — согласование с bounded contexts из 03.06.02 Основы Domain-Driven Design. Прямой доступ модуля «Платежи» к таблицам «Каталога» минуя «Заказы» — типичный сигнал неверной границы.

2.6. Shared-модули и сквозная ответственность

Элемент, который нельзя отдать одной команде, помечайте shared и классифицируйте тип — от этого зависят контракт и трассировка:

Тип sharedЧто этоРискКак не превратить в God Module
Shared libraryОбщий код без состояния (утилиты, клиенты, SDK)Раздувание зависимостейУзкий публичный API; версионирование; без бизнес-правил
Shared dataСправочник или read-модель с несколькими потребителямиКонфликт измененийОдин владелец-куратор; остальные — только чтение или события
Оркестратор сценарияКоординирует шаги нескольких подсистем (saga, BPMN)Скрытая бизнес-логика «посередине»Только координация и компенсации; доменная логика — у владельцев шагов

Трассировка: shared library — одна строка в 10.01.15 Шаблон матрицы трассировки с перечислением потребителей; shared data и оркестратор — отдельные строки с несколькими заинтересованными командами в колонке владельца требований, но одним техническим модулем-владельцем.

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

3.1. Методы логической декомпозиции

Метод выбирают по природе системы и доступным моделям; на практике методы комбинируют, а не выбирают один навсегда. Разрез по единицам развёртывания (микросервисы, контейнеры) — не метод логической декомпозиции, а шаг физического отображения (см. п. 8 процесса и 03.06.01 Архитектурные паттерны распределённых систем).

МетодСутьКогда применятьПример
ФункциональнаяРазбиение по процессам и подфункциямЧёткие бизнес-процессы, документооборот03.04.02 Диаграмма потоков данных (DFD), 03.04.03 IDEF0 и его применение
Структурная (по данным)Разбиение по сущностям и связямCRM, ERP, data-centric системыПодсистемы «Клиенты», «Договоры» на основе 03.03.01 ER-диаграммы (сущность-связь)
Объектно-ориентированнаяГруппировка классов в пакетыOO-разработка, сложная логика06.01.01 Структурные диаграммы (Class, Object, Package)
Предметно-ориентированная (DDD)Ограниченные контексты (Bounded Contexts)Сложная предметная область, разные модели одного термина03.06.02 Основы Domain-Driven Design
По слоямГоризонтальные слои внутри модулейWeb-приложения, многоуровневые архитектурыСлои внутри модуля «Оформление заказа», не отдельная подсистема «Сервисы»

Если методы дают разные границы (BPMN режет по процессам, ER — по сущностям): зафиксируйте расхождения на 02.02.02 Воркшопы, фасилитация и совместные сессии, назовите части единым глоссарием, выберите ведущий критерий для верхнего уровня (обычно бизнес-способность или bounded context), второй метод используйте для проверки и уточнения модулей. Противоречия оформляйте через 10.01.13 Шаблон архитектурного решения (ADR).

Входные модели для шагов анализа: 03.02.01 Диаграмма прецедентов (Use Case Diagram), 03.04.01 BPMN 2.0 - введение и основы, 03.02.02 Диаграмма деятельности (Activity Diagram).

3.2. Критерии остановки декомпозиции

Остановитесь, когда выполнено достаточно для текущей фазы — концепт, MVP и детальное проектирование требуют разной глубины:

ФазаДостаточный уровеньЭвристика глубины
Концепт / VisionПодсистемы (capabilities) без детализации модулей3–7 подсистем на продукт — ориентир для обсуждения
MVPПодсистемы первого релиза; один модуль на подсистему или без модульного уровня — нормаНе дробите backlog искусственно
Детальное проектированиеУ каждой релевантной подсистемы 3–7 модулей с понятными именамиДальше — уровень компонентов/классов (зона разработки)

Дополнительные критерии для любой фазы:

  • Атомарность ответственности — модуль описывается одним предложением без «и» между несвязанными обязанностями.
  • Трассируемость — к модулю можно привязать набор требований или capability; в матрице трассировки модуль — строка или группа строк. Зафиксируйте соглашение об идентификаторе (например, MOD-CAT-SEARCH для модуля «Поиск» в подсистеме «Каталог») — он связывает диаграмму, SRS и 10.01.15 Шаблон матрицы трассировки.
  • Владение данными — для ключевых сущностей указан owning module и режим доступа соседей (см. § 2.5).
  • Команда и релиз — модуль или подсистема укладывается в зону ответственности одной команды или явно помечена как shared с типом из § 2.6.
  • Интерфейсы — для каждой границы между модулями понятен контракт (синхронный вызов, событие, общий справочник); версионирование — 03.05.07 Управление версионированием API и жизненным циклом.
  • НФТ и модульность — границы учитывают изоляцию данных, аудит, отказоустойчивость, регуляторные контуры (08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 08.06 Юридические и регуляторные требования РФ (PCI-DSS)); modularity как атрибут сопровождаемости — в ISO/IEC 25010.

Слишком мелкий разрез (наносервисы) и слишком крупный (God Module) — сигналы продолжить или укрупнить декомпозицию.

3.3. Пошаговый процесс

  1. Контекст — 03.01.02 Моделирование контекста системы (Context Diagram): внешние акторы и потоки.
  2. Capability map и требования — сгруппируйте цели и KPI (02.01.02 Цели, KPI и критерии успеха (SMART, GQM)) в карту бизнес-способностей; на её основе — классификация и группировка требований (02.03.01 Классификация требований (БТ, ФТ, НФТ)). На ArchiMate capability map соответствует 06.03.02 Бизнес-слой.
  3. Подсистемы — кандидаты с одной бизнес-способностью, минимальным числом соседей, согласованные со scope релиза (02.01.04 Определение границ решения (Scope Modelling)).
  4. Модули — внутри подсистемы: группы тесно связанных функций; activity diagram или сценарии (03.02.02 Диаграмма деятельности (Activity Diagram)). На концепте/MVP шаг можно пропустить или оставить один модуль-заглушку на подсистему.
  5. Владение данными — таблица сущность → владелец → режим доступа (§ 2.5).
  6. Интерфейсы — операции и данные на каждой границе; 03.01.04 Интерфейсы и интеграционные взаимодействия, при асинхронности — 03.05.06 Event-Driven Architecture.
  7. Проверка LCHC — связность, связанность, отсутствие циклов на уровне модулей и подсистем (циклы между компонентами внутри модуля допустимы, но их стоит локализовать).
  8. Физическое отображение — какие модули попадают в какие контейнеры и артефакты развёртывания; при необходимости — deployment-диаграмма и 03.06.01 Архитектурные паттерны распределённых систем.
  9. Согласование и V&V — структура покрывает scope, не противоречит контекстной диаграмме, согласована с архитектором и ключевыми стейкхолдерами (02.04.01 Верификация и валидация (V&V), 08.04 Рецензирование и инспекции (техники Фейгана)).
  10. Документирование — диаграмма декомпозиции, глоссарий модулей с идентификаторами, ADR для спорных границ; трассировка в 10.01.15 Шаблон матрицы трассировки. Куда класть результат: обзор подсистем — в Vision & Scope / раздел архитектуры BRD; детализация модулей, интерфейсов и data ownership — в SRS или архитектурном описании (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)); спорные границы — только в 10.01.13 Шаблон архитектурного решения (ADR).

LLM могут ускорить черновик capability map, но не заменяют согласованный артефакт — см. 11.07 Практические кейсы применения LLM в анализе.

3.4. Моделирование

НотацияРоль в декомпозиции
UML PackageЛогическая иерархия модулей
UML ComponentЗаменяемые части и интерфейсы внутри модуля
DFDФункциональная иерархия процессов → подсистемы
06.03.05 C4-модельContext (система) → Container (развёртывание) → Component (логические модули) — уровни не смешивать
ArchiMate (прикладной слой)Сервисы и компоненты приложения — 06.03.03 Прикладной и технологический слои
Mind mapЭскиз на ранних воркшопах

Пример логической иерархии (пунктир — сценарный поток «заказ → оплата»; прямые зависимости между модулями разных подсистем идут через интерфейсы, а не через обход владельца данных — ошибка «Payment → Catalog» минуя Order здесь намеренно отсутствует):

graph TD
    subgraph ShopSystem["Интернет-магазин (логический уровень)"]
        subgraph Catalog["Подсистема Каталог"]
            Search["MOD-CAT-SEARCH"]
            Filter["MOD-CAT-FILTER"]
            ProductCard["MOD-CAT-CARD"]
        end
        subgraph Order["Подсистема Обработка заказов"]
            Cart["MOD-ORD-CART"]
            Checkout["MOD-ORD-CHECKOUT"]
            History["MOD-ORD-HISTORY"]
        end
        subgraph Payment["Подсистема Платежи"]
            Gateway["MOD-PAY-GATEWAY"]
            Refund["MOD-PAY-REFUND"]
        end
    end
    Catalog -.->|"сценарий: оформление"| Order
    Order -.->|"сценарий: оплата"| Payment
    Checkout -->|"API: создать платёж"| Gateway

3.5. Проверочный чек-лист

Логический уровень:

  • Подсистема = одна ключевая бизнес-способность.
  • Модули с высокой функциональной связностью; низкая связанность через интерфейсы.
  • Нет циклических зависимостей между модулями/подсистемами.
  • Одна ответственность не дублируется (DRY на уровне обязанностей).
  • Имена понятны бизнесу и разработчикам.
  • Изменение в одной предметной области затрагивает преимущественно один модуль.
  • К каждому модулю привязан блок требований в матрице трассировки с идентификатором.
  • Для доменных сущностей указан owning module; нет скрытого shared state.

Shared и физический уровень (если уже определён):

  • Shared-элементы классифицированы (library / data / оркестратор); нет God Module.
  • Границы согласованы с командами (закон Конвея; организационное выравнивание — 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках; детали Team Topologies — вне scope базы, см. Skelton & Pais).
  • Модуль или контейнер можно тестировать с приемлемой изоляцией.
  • НФТ (производительность, безопасность, compliance) не нарушены выбранным разрезом.

3.6. Модульный монолит и эволюция

Модульный монолит (Modular Monolith) — одно развёртывание с жёсткими логическими границами между модулями; часто стартовая точка перед выделением сервисов. Эволюционное выделение модуля из монолита (strangler) стыкуется с 10.02 Разбор кейса "Миграция legacy-системы". Детали паттернов развёртывания — в 03.06.01 Архитектурные паттерны распределённых систем, не дублируйте их здесь.

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

  • Смешение логики и развёртывания — микросервис нарисован как «модуль» без отдельной логической диаграммы; команды и тесты проектируются по физическому разрезу, который не отражает домен.
  • Слишком мелкая грануляция — наносервисы, операционный хаос; на MVP — искусственное дробление «ради 3–7 модулей».
  • God Module — одна «куча» бизнес-логики, UI и данных; часто результат неклассифицированного shared.
  • Технические модули вместо доменных — «Валидация», «Логирование» наравне с «Заказами» (см. раздел «Слои внутри модуля vs «технические» модули»).
  • Распределённый монолит — формально отдельные сервисы, фактически общая БД и жёсткие синхронные цепочки без явного data ownership (03.06.01 Архитектурные паттерны распределённых систем).
  • Копирование оргструктуры — модули повторяют текущие отделы; при смене структуры ломается архитектура. Компенсация: воркшоп по deliberate architecture (02.02.02 Воркшопы, фасилитация и совместные сессии), выравнивание по домену, затем согласование с командами (05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках).
  • Игнорирование НФТ — декомпозиция без учёта latency, границ персональных данных, аудита, PCI (08.02 Нефункциональные требования (НФТ) — классификация и стандарты).
  • Конфликтующие модели без решения — разные имена подсистем из BPMN и ER без глоссария и ADR.
  • Декомпозиция без согласования — структура не прошла ревью со стейкхолдерами и не проверена на покрытие scope.

Декомпозиция эволюционирует: на ранних этапах достаточно подсистем MVP без модульного уровня; детализация нарастает по мере уточнения требований и 02.05.01 Управление зависимостями между требованиями.

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

Входы (откуда брать материал для разреза):

Выходы (куда ведёт результат):

Верификация и смежные приёмы:

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

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

  • Glenford J. Myers. «Composite/Structured Design». Van Nostrand Reinhold, 1978. — связность и связанность модулей. ISBN: 0442805845.
  • Larry L. Constantine, Edward Yourdon. «Structured Design». Prentice-Hall, 1979. — классика структурного проектирования, шкалы cohesion/coupling.
  • David L. Parnas. «On the Criteria to Be Used in Decomposing Systems into Modules». Communications of the ACM, 1972. — сокрытие информации. https://doi.org/10.1145/361598.361623
  • ISO/IEC 25010:2011 — модульность и сопровождаемость в модели качества. https://www.iso.org/standard/35733.html
  • Eric Evans. «Domain-Driven Design». Addison-Wesley, 2004. — bounded contexts. ISBN: 0321125215.
  • Martin Fowler. «Patterns of Enterprise Application Architecture». Addison-Wesley, 2002. — модульность корпоративных приложений.
  • Matthew Skelton, Manuel Pais. «Team Topologies». IT Revolution, 2019. — согласование архитектуры и команд (вне детального разбора в базе).
  • Sam Newman. «Building Microservices». O'Reilly, 2021. — декомпозиция для распределённых систем.
  • Simon Brown. C4 Model — уровни визуализации архитектуры. https://c4model.com (в базе: 06.03.05 C4-модель).
  • BABOK Guide v3, глава 7 «Requirements Analysis and Design Definition» — организация и декомпозиция требований (обзор стандартов: 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)).
  • SEBoK — System Architecture, принципы архитектурной декомпозиции (там же).

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