Часто задаваемые вопросы

Какова предыстория модели C4?

Модель C4 была создана Саймоном Брауном, который начал преподавать архитектуру программного обеспечения, работая разработчиком программного обеспечения/архитектором. Частью учебного курса Саймона было упражнение по проектированию, во время которого группам людей предъявляли некоторые требования, просили выполнить какой-либо дизайн и нарисовать несколько диаграмм, чтобы выразить этот дизайн.

Хотя это было упражнение, ориентированное на дизайн, большое разнообразие диаграмм показало, что визуализация идей - это навык, которого остро не хватает большинству людей. Модель C4, по сути, является формализацией того, как Саймон использовал для визуализации архитектуры программного обеспечения, которая развивалась на протяжении многих лет.

Точные даты установить сложно, но истоки модели C4 можно проследить где-то в районе 2006-2009 годов, а типы диаграмм (“контекст”, “контейнеры”, “компоненты”, “классы”) были названы в начале 2010 года, причем название “C4” было впервые был использован в начале 2011 года. Четвертый тип диаграммы был переименован из “классов” в “код” в течение 2015-2016 годов.

Что послужило источником вдохновения для модели C4?

Модель C4 была создана в то время, когда команды, находящиеся под влиянием движения agile, не проявляли особого энтузиазма по поводу использования унифицированного языка моделирования (UML) для документирования архитектуры программного обеспечения, если они вообще создавали диаграммы. Несмотря на это, модель C4 была основана на UML и модели 4+1 для архитектуры программного обеспечения. Таким образом, вы можете рассматривать модель C4 как упрощенную версию базовых концепций, разработанную для (1) упростить разработчикам программного обеспечения описание и понимание того, как работает программная система, и (2) свести к минимуму разрыв между моделью/описанием архитектуры программного обеспечения и исходным кодом.

Не является ли модель C4 шагом назад? Почему вы изобретаете UML заново? Почему бы просто не использовать UML?

Рассматриваете ли вы модель C4 как шаг вперед или шаг назад, зависит от того, где вы находитесь. Если вы используете UML (или SysML, ArchiMate и т.д.), И это работает у вас, придерживайтесь этого. К сожалению, использование UML, похоже, идет на спад, и многие команды снова вернулись к использованию для этого случая диаграммы с квадратами и линиями. Учитывая, что многие из этих команд не хотят использовать UML (по разным причинам), модель C4 помогает привнести некоторую структуру и дисциплину в процесс взаимодействия с архитектурой программного обеспечения. Для многих команд модель C4 является достаточной. А для других, возможно, это шаг вперед в UML.

Почему модель C4 не охватывает бизнес-процессы, рабочие потоки, конечные автоматы, модели предметной области, модели данных и т.д.?

Основное внимание в модели C4 уделяется статическим структурам, составляющим программную систему, на разных уровнях абстракции. Если вам нужно описать другие аспекты, не стесняйтесь дополнять диаграммы C4 диаграммами UML, диаграммами BPMN, Диаграммами ArchiMate, диаграммами взаимосвязей сущностей и т.д.

Подразумевает ли модель C4 процесс проектирования или структуру команды?

Распространенным заблуждением является то, что процесс проектирования в команде должен соответствовать уровням иерархии моделей C4, возможно, разные люди в команде отвечают за разные уровни диаграмм. Например, бизнес-аналитик создает контекстную диаграмму системы, архитектор создает контейнерную диаграмму, в то время как разработчики заботятся об остальных уровнях детализации.

Хотя вы, безусловно, можете использовать модель C4 таким образом, это не предполагаемый и не рекомендуемый способ использования. То Модель C4 - это всего лишь способ описания программной системы с разных уровней абстракции, и она ничего не говорит о процессе разработки программного обеспечения.

Используете C4 для описания библиотек, фреймворков и SDK?

Модель C4 на самом деле предназначена для моделирования программной системы на различных уровнях абстракции. Для документирования библиотеки, фреймворка или SDK, возможно, лучше использовать что-то вроде UML. В качестве альтернативы вы могли бы использовать модель C4 для описания примера использования вашего фреймворка, библиотеки или SDK; возможно, используя цветовое кодирование, чтобы указать, какие части программной системы созданы на заказ, а какие предоставлены вам.

Является ли модель C4 универсально применимой?

Модель C4 была разработана для того, чтобы помочь описывать, документировать и создавать схемы специально разработанных программных систем. С этой точки зрения модель C4 может быть использована для описания различных архитектур программного обеспечения (монолитных или распределенных), построенных на различных языках программирования, развернутых на различных платформах (локальных или облачных).

К решениям, которые, возможно, в меньшей степени подходят для модели C4, относятся встроенные системы/микропрограммное обеспечение, а также решения, которые основаны на сложной настройке, а не на разработке на заказ (например, SAP и Salesforce). Даже при использовании этих решений вы все равно можете счесть полезными системный контекст и схемы контейнеров.

Масштабируется ли модель C4?

Удобно, что диаграммы-примеры состоят из небольшого количества прямоугольников и стрелок, но вы можете спросить, как модель C4 может быть использована в реальных программных системах, где у вас 600 компонентов, а не 6. Ответ заключается в том, что выбранный вами инструмент может как помочь, так и помешать вам.

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

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

Вот пример схемы контейнера, показывающей программную систему, состоящую из нескольких микросервисов:

На данный момент эта схема работает, но по мере добавления новых сервисов она будет быстро усложняться. В качестве альтернативного подхода, вместо создания единой диаграммы, показывающей 8 служб, мы могли бы создать 8 диаграмм, каждая из которых посвящена одной службе и показывает ближайшие афферентные (входящие) и эфферентные (исходящие) зависимости:

Service 1	Service 2	Service 3

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