Диаграмма компонентов

Компонент не обязан совпадать с классом, пакетом или контейнером. Им может быть клиентское приложение, серверный API, модуль оплаты, адаптер внешней системы или сервис уведомлений — то есть часть, которую можно обсуждать через её внешний контракт.

Формально компонент относится к структурированным классификаторам: он может иметь поведение, внутренние части, порты и соединители. На диаграмме компонентов обычно оставляют только внешнюю ответственность и контракты; внутреннюю структуру раскрывают лишь при необходимости.

Предоставляемый интерфейс обозначает возможность компонента, требуемый — контракт, необходимый ему для работы. Реализация связывает компонент с предоставляемым контрактом, а зависимость (Dependency) или требуемый интерфейс (required interface) показывает потребность в другом контракте.

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

Проверка диаграммы

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

В модели

Диаграмма опирается на проектные решения и программную архитектуру. Группировку модулей показывает диаграмма пакетов, внутренности одного компонента — диаграмма внутренней структуры, а физическое окружение — диаграмма развёртывания.

Представление компонентов C4 группирует связанную функциональность внутри одного контейнера C4. Оно не равно UML-компоненту, поэтому формальные интерфейсы и порты остаются предметом этой диаграммы.