Модель C4 (C4 model) для визуализации архитектуры программного обеспечения

26.10.21

Архитектура

Перевод главной страницы сайта https://c4model.com/, посвященной C4 model.

Вступление

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

Как стандарты отрасли, у нас есть Унифицированный язык моделирования (UML), ArchiMate и SysML, но вопрос о том, обеспечивают ли они эффективный способ передачи архитектуры программного обеспечения, часто неуместен, потому что многие команды уже отказались от них в пользу гораздо более простых диаграмм "прямоугольников и линий". Отказ от этих языков моделирования - это одно, но, возможно, в гонке за гибкостью многие команды разработчиков программного обеспечения потеряли способность к визуальному общению.

 

Схемы вашего кода

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

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

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

 

Абстракции

Чтобы создать эти карты вашего кода, нам сначала нужен общий набор абстракций для создания повсеместного языка, который мы можем использовать для описания статической структуры программной системы. Модель C4 рассматривает статические структуры программной системы (software system) с точки зрения контейнеров (containers), компонентов (componentsи кода (code) и людей (people) использующих программные системы, которые мы создаем.

Программная система состоит из одного или нескольких контейнеров (веб-приложений, мобильных приложений, настольных приложений, баз данных, файловых систем и т.д.), Каждый из которых содержит один или несколько компонентов, которые, в свою очередь, реализуются одним или несколькими элементами кода (например, классы, интерфейсы, объекты, функции и т.д.):

 

Человек (Person)

Человек представляет одного из пользователей вашей программной системы (например, акторов, ролей, персонажей и т.д.).

Программная система (Software System)

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

Контейнер (Container) 

(приложения и хранилища данных)

Не Docker! В модели C4 контейнер представляет приложение или хранилище данных. Контейнер - это то, что должно быть запущено для работы всей программной системы. В реальном выражении контейнер - это что-то вроде:

  • Серверное веб-приложение: Веб-приложение Java EE, работающее на Apache Tomcat, ASP.NET Приложение MVC, работающее на Microsoft IIS, приложение Ruby on Rails, работающее на WEBrick, Node.js применение и т.д.
  • Веб-приложение на стороне клиента: Приложение JavaScript, работающее в веб-браузере с использованием Angular, Backbone.JS, jQuery и т.д.
  • Клиентское настольное приложение: Настольное приложение Windows, написанное с использованием WPF, настольное приложение OS X, написанное с использованием Objective-C, кроссплатформенное настольное приложение, написанное с использованием JavaFX, и т.д.
  • Мобильное приложение: Приложение Apple iOS, приложение для Android, приложение Microsoft Windows Phone и т.д.
  • Консольное приложение на стороне сервера: Автономное (например, "public static void main") приложение, пакетный процесс и т.д.
  • Бессерверная функция: Одна бессерверная функция (например, Amazon Lambda, функция Azure и т.д.).
  • База данных: Схема или база данных в системе управления реляционными базами данных, хранилище документов, графическая база данных и т.д., Такие как MySQL, Microsoft SQL Server, база данных Oracle, MongoDB, Riak, Cassandra, Neo4j и т.д.
  • Хранилище больших двоичных объектов или контента: Хранилище больших двоичных объектов (например, Amazon S3, хранилище больших двоичных объектов Microsoft Azure и т.д.) Или сеть доставки контента (например, Akamai, Amazon CloudFront и т.д.).
  • Файловая система: Полная локальная файловая система или часть более крупной сетевой файловой системы (например, SAN, NAS и т. Д.).
  • Сценарий оболочки: Один сценарий оболочки, написанный на Bash и т.д.
  • и т.д.

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

Компонент (Component)

Слово "компонент" является чрезвычайно перегруженным термином в индустрии разработки программного обеспечения, но в данном контексте компонент представляет собой группу связанных функций, инкапсулированных за четко определенным интерфейсом. Если вы используете такой язык, как Java или C#, самый простой способ представить компонент как набор классов реализации за интерфейсом. Такие аспекты, как упаковка этих компонентов (например, один компонент против множества компонентов в файле JAR, DLL, общей библиотеке и т.д.), Являются отдельной и ортогональной проблемой.

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

 

Основные диаграммы

Визуализация этой иерархии абстракций выполняется путем создания коллекции диаграмм контекста (Context), контейнеров (Container), компонент (Component) и (необязательно) кода (Code) (например, класса UML). Именно отсюда модель C4 получила свое название.

Уровень 1: Схема системного контекста

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

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

Область применения: Единая программная система.

Основные элементы: Программная система в объеме.

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

Целевая аудитория: Все, как технические, так и нетехнические люди, внутри и за пределами команды разработчиков программного обеспечения.

Рекомендуется для большинства команд: Да.

 

Уровень 2: Схема контейнеров

Как только вы поймете, как ваша система вписывается в общую ИТ-среду, действительно полезным следующим шагом будет уточнение границ системы с помощью диаграммы контейнеров. "Контейнер" - это что-то вроде серверного веб-приложения, одностраничного приложения, настольного приложения, мобильного приложения, схемы базы данных, файловой системы и т.д. По сути, контейнер - это отдельно запускаемый/развертываемый модуль (например, отдельное пространство процесса), который выполняет код или хранит данные.

Схема контейнера показывает высокоуровневую форму архитектуры программного обеспечения и то, как распределяются обязанности между её узлами. Она также показывает основные технологические решения и то, как контейнеры взаимодействуют друг с другом. Это простая, ориентированная на технологии диаграмма высокого уровня, которая полезна как разработчикам программного обеспечения, так и персоналу службы поддержки/эксплуатации.

Область применения: Единая программная система.

Основные элементы: Контейнеры в пределах области действия программной системы.

Вспомогательные элементы: Люди и программные системы, непосредственно подключенные к контейнерам.

Целевая аудитория: Технические специалисты внутри и за пределами команды разработчиков программного обеспечения; в том числе архитекторы программного обеспечения, разработчики и операционный/вспомогательный персонал.

Рекомендуется для большинства команд: Да.

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

 

Уровень 3: Схема компонентов

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

Диаграмма компонентов показывает, как контейнер состоит из нескольких "компонентов", каковы каждый из этих компонентов, их обязанности и детали технологии/реализации.

Область применения: Один контейнер.

Основные элементы: Компоненты внутри контейнера в области действия.

Вспомогательные элементы: Контейнеры (в пределах области применения программной системы) плюс люди и программные системы, непосредственно подключенные к компонентам.

Целевая аудитория: Архитекторы и разработчики программного обеспечения.

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

 

Уровень 4: Код

Наконец, вы можете увеличить масштаб каждого компонента, чтобы показать, как он реализован в виде кода; используя диаграммы классов UML, диаграммы отношений сущностей или аналогичные.

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

Область применения: Один компонент.

Основные элементы: Элементы кода (например, классы, интерфейсы, объекты, функции, таблицы базы данных и т.д.) в пределах области действия компонента.

Целевая аудитория: Архитекторы и разработчики программного обеспечения.

Рекомендуется для большинства команд: Нет, для долговременной документации большинство IDE могут генерировать такой уровень детализации по требованию.

 

Дополнительные диаграммы

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

Схема ландшафта системы

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

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

Сфера применения: Предприятие.

Основные элементы: Люди и программные системы, относящиеся к предприятию по сфере деятельности.

Целевая аудитория: Технические и нетехнические специалисты, как внутри, так и за пределами команды разработчиков программного обеспечения.

 

Динамическая диаграмма

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

Область применения: Предприятие, программная система или контейнер.

Основные и вспомогательные элементы: Зависит от области применения схемы; предприятие (см. Схему системного ландшафта), программная система (см. Системный контекст или Схемы контейнеров), контейнер (см. Схему компонентов).

Целевая аудитория: Технические и нетехнические специалисты, как внутри, так и за пределами команды разработчиков программного обеспечения.

 

Схема развертывания

Схема развертывания позволяет проиллюстрировать, как программные системы и/или контейнеры в статической модели сопоставляются с инфраструктурой. Эта схема развертывания основана на схеме развертывания UML, хотя и немного упрощена, чтобы показать сопоставление между контейнерами и узлами развертывания. Узел развертывания - это что-то вроде физической инфраструктуры (например, физический сервер или устройство), виртуализированной инфраструктуры (например, IaaS, PaaS, виртуальная машина), контейнерной инфраструктуры (например, контейнер Docker), среды выполнения (например, сервер базы данных, веб-сервер/сервер приложений Java EE, Microsoft IIS) и т.д. Узлы развертывания могут быть вложенными.

Вы также можете включить узлы инфраструктуры, такие как службы DNS, балансировщики нагрузки, брандмауэры и т.д.

Область применения: Одна или несколько программных систем.

Основные элементы: узлы развертывания, экземпляры программных систем и экземпляры контейнеров.

Вспомогательные элементы: Узлы инфраструктуры, используемые при развертывании программной системы.

Целевая аудитория: Технические специалисты внутри и за пределами команды разработчиков программного обеспечения; в том числе архитекторы программного обеспечения, разработчики, архитекторы инфраструктуры и операционный/вспомогательный персонал.

 

Обозначения

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

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

 

C4 и UML

Хотя приведенные выше примеры диаграмм созданы с использованием обозначения "прямоугольники и линии", основные диаграммы могут быть проиллюстрированы с использованием UML с соответствующим использованием пакетов, компонентов и стереотипов. Однако результирующим диаграммам UML, как правило, не хватает одинаковой степени описательного текста, поскольку добавление такого текста невозможно (или сложно) с помощью некоторых инструментов UML.

Вот три примера системного контекста, контейнера и диаграммы компонентов для сравнения.

 

C4 и ArchiMate

См. C4 model, Точка зрения архитектуры и Archi 4.7 для получения подробной информации о том, как создавать диаграммы моделей C4 с помощью ArchiMate.

 

Ключи/легенда диаграммы

Любая используемая нотация должна быть как можно более самоописывающейся, но все диаграммы должны иметь ключи/легенду, чтобы сделать нотацию явной. Это относится и к диаграммам, созданным с использованием таких обозначений, как UML, ArchiMate и SysML, так как не все будут знать используемые обозначения.

 

Обозначения, обозначения, обозначения

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

И вот некоторые рекомендации, связанные с обозначениями.

Диаграммы Элементы Отношения
  • Каждая схема должна иметь заголовок, описывающий тип и область применения схемы (например, "Схема системного контекста для моей программной системы").
  • Каждая диаграмма должна иметь ключ/легенду, объясняющую используемые обозначения (например, формы, цвета, стили границ, типы линий, стрелки и т.д.).
  • Сокращения и аббревиатуры (бизнес/домен или технология) должны быть понятны всем аудиториям или объяснены в ключе/легенде диаграммы.
  • Тип каждого элемента должен быть явно указан (например, Человек, Программная система, Контейнер или Компонент).
  • Каждый элемент должен иметь краткое описание, чтобы дать "краткое" представление о ключевых обязанностях.
  • Для каждого контейнера и компонента должна быть явно указана технология.
  • Каждая строка должна представлять однонаправленную связь.
  • Каждая строка должна быть помечена, метка должна соответствовать направлению и цели отношений (например, зависимости или потоку данных). Старайтесь быть как можно более конкретным с этикеткой, в идеале избегая отдельных слов, таких как "Использует".
  • Отношения между контейнерами (обычно они представляют собой межпроцессную связь) должны иметь явно обозначенную технологию/протокол.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Техническое дополнение (от переводчика)

Нотацию C4 можно использовать в PlantUML диаграммах (пишем текст, который преобразуется в диаграмму), https://github.com/plantuml-stdlib/C4-PlantUML

Можно перевести чек лист проверки диаграммы и оформить в PDF, если нужно пишите в комментарии - дополню статью.

 

Благодарю за внимание.

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1422    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1640    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    3828    0    ivanov660    10    

29

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1819    0    user1754524    15    

15

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    2858    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9584    0    1c-izhtc    37    

21

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1384    0    Ingraf    0    

15
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. ogroup 279 26.10.21 09:23 Сейчас в теме
Допустим. Но как можно описать лютую самописную конфигурацию с миллионом дополнительных функций и особенностей через C4 так, чтобы понимание сути пришло быстрее, чем через разбор самого кода? Моя не понимать.
11. mikukrnet 181 28.02.23 13:11 Сейчас в теме
(1) старого монстра нет смысла описывать, а вот для новых проектов - самое оно
2. Hans 2 26.10.21 10:54 Сейчас в теме
Некликабельные картинки специально сделал?
3. malikov_pro 1292 26.10.21 12:19 Сейчас в теме
(2) Последние по сравнению с UML скриншотом сделал, остальные перенес в полном размере и подогнал по ширине, как в теле статьи сделать кликабельными не знаю. Тон чуть уважительнее. Посмотрю как можно сделать более удобными, по идее их нужно перерисовать с русскими аннотациями.
4. malikov_pro 1292 26.10.21 12:30 Сейчас в теме
(1) Описать для кого и как потом эту схему собираетесь переиспользовать?
"чтобы понимание сути пришло быстрее" - думаю смотреть в выделение доменов и делать их декомпозицию, сам DDD и подобное осваиваю. На данный момент в практике смотрю доработки и формирую список функциональных требований, дальше смотрю их актуальность и возможность переноса на новые версии типовых, со скрипом, но хватает.

"Моя не понимать." - решается через попытки моделирования в заинтересованной группе (тех кто может дать адекватную обратную связь по понятности и полноте). Из моей деятельности думаю как описать понятно разницу между обменом с сайтом по CML и API например. Если есть желание то можем собраться в конференции (зум, скайп) и попробовать смоделировать.
5. chng 26.10.21 14:29 Сейчас в теме
А какой инструмент можно взять и попытаться порисовать в этой нотации, хотябы в демо режиме?
6. malikov_pro 1292 26.10.21 15:23 Сейчас в теме
(5) если графически, то https://github.com/tobiashochguertel/c4-draw.io, сам моделирую через текст https://github.com/plantuml-stdlib/C4-PlantUML. Если есть желание можно совместно попрактиковаться на обоим интересном контексте.
8. chng 26.10.21 16:13 Сейчас в теме
(6) Спасибо!

>...сам моделирую через текст...

всегда интересовало, в чем польза моделировать текстом это же в разы трудозатратнее?
9. malikov_pro 1292 26.10.21 20:36 Сейчас в теме
(8) Если не ставить задачей "красиво расставить блоки" то получается быстрее. Сначала формирую список объектов и их свойства, после описываю связи. модель иногда формирую при клиенте при анализе контекста задачи: у вас есть ...? - да, записал object ..., ... связано с ...? - да, записал ... --> ...
Правило 7+-2 еще четче срабатывает. Если схема текстом не влезает на экран, то и на диаграмме будет перегруз.
10. maxim.samokhval 24.12.21 15:41 Сейчас в теме
12. malikov_pro 1292 01.03.23 06:58 Сейчас в теме
(11) Вы не правы. Описывать текущие системы полезно, улучшает понимание происходящего и лучше выстраивается план преобразования. Вариант совместить анализ кода, опрос пользователей и программистов поддерживающих код. Если нарисуете схему что окружающие +- скажут что понятно как и что так и работает то как опора для дальнейшего развития хорошая. У меня частый кейс описания функции/формы/блока для актуализации его варианта использования. Самому для этого бумаги хватает.

Думаю будет полезно по теме
"Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин."
13. user2003284 18.10.23 17:31 Сейчас в теме
Может ли Software System влючать в себя другую Software System? А Container - другой Container?
14. пользователь 07.11.23 16:07
Сообщение было скрыто модератором.
...
Оставьте свое сообщение