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

Можем ли мы изменить терминологию?

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

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

Можем ли мы добавить больше уровней абстракции?

“База данных - это база данных; спорить о том, является ли она также контейнером или компонентом, просто не имеет смысла”.

Эта цитата из [записи в блоге] (https://www.ilograph.com/blog/posts/concrete-diagramming-models/) поднимает пару интересных вопросов о модели C4:

1. Не слишком ли ограничены четыре уровня абстракции?
2. Можем ли мы добавить больше уровней абстракции?

Современные программные системы состоят из множества различных типов компонентов времени компиляции, среды выполнения, развертывания и инфраструктуры. Учитывая это, иногда бывает трудно отнести каждый из них к различным абстракциям, составляющим модель C4. Казалось бы, более простой подход заключается в том, чтобы просто добавить дополнительные уровни абстракции по мере необходимости, вместо того чтобы тратить время на обсуждение того, является ли “база данных” контейнером или компонентом.

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

“микросервисы не должны совместно использовать базу данных”

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

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

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

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