[Анализ и проектирование систем] Как описать архитектуру продукта по нотации C4 (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 8 месяцев
Сообщений: 27286
Когда мы начали создавать платформу True Engineering, в компании не было единых правил для оформления архитектуры. Разные команды – разные инструменты, разные обозначения и уровни абстракции. Значит, даже подобные решения сравнить между собой не получится, а тому, кто смотрит на архитектуру проекта в первый раз, обычно нужен проводник, который расскажет, что же тут изображено. Мы решили унифицировать подходы с помощью модели С4, которая обеспечивает всестороннее описание программных архитектур.Сама по себе такая задача описания архитектуры, мягко говоря, не новая, и решить её можно несколькими способами:· MS Visio и подобные редакторы – громоздко, малоудобно. Эти средства создавались для иных целей, и это заметно.· UML – эти диаграммы быстро увеличиваются в количестве, довольно скоро их становится сложно поддерживать. К тому же фактически нужно всегда иметь в виду масштаб всей системы.· 4+1 – снова проблемы с поддержкой и масштабом, высокий порог входа для новых участников команды.В C4 многих этих проблем нет. Она объединяет 4 иерархических уровня: (1) Context, (2) Container, (3) Component, (4) Code.
Как можно прочитать на сайте по модели C4, создал её лондонский программный архитектор Саймон Браун (Simon Brown) в рамках своего учебного курса. В программе было упражнение, когда участников просили разработать архитектуру продукта по заданным требованиям. Браун увидел, что нарисовать несколько диаграмм, чтобы выразить замысел, оказалось сложнее, нежели он представлял. И разработал систему для формализованного подхода к архитектуре ПО.Зачем создали модель C4· Чтобы помочь командам описывать архитектуру как при предварительном проектирования, так и при ретроспективном документировании кодовой базы· Чтобы создавать карты кода на разных уровнях детализации – автор приводит в пример Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.· Чтобы дать архитекторам, разработчикам, PM-ам и аналитикам абстрактные модели для работы с архитектурным схемами.Теперь о том, что это за абстракции и на каких уровнях они существуют.Уровень 1. Диаграмма системного контекста (System Context) обеспечивает отправную точку, которая показывает, как программная система вписывается в окружающий ее мир.Здесь описываются функции, которые приносят пользу пользователям. Уровень включает в себя и сам продукт, и другие взаимосвязанные с ними системы.
Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а пользователи, роли, акторы, программные системы. С этой диаграммой будет легко работать бизнес-заказчикам и не-техническим людям.Уровень 2: Как только вы поймете, как ваша система вписывается в общую ИТ-среду, следующий шаг - увеличить масштаб до высокоуровневых строительных блоков. Диаграмма контейнера (Container) показывает общую форму архитектуры, распределение функций и обязанностей. 
Не путать с Docker-контейнерами – в C4 контейнер представляет то, что необходимо запустить для работы всего продукта. Например, серверное, мобильное или веб-приложение, клиентская программа, БД, бессерверная функция, shell-скрипт.Каждый контейнер – это отдельно развертываемый объект или среда выполнения, которая зачастую работает в собственном пространстве процессов. Из-за этого связь между контейнерами обычно принимает форму межпроцессного взаимодействия.Такая диаграмма полезна как команде разработчиков, так и службе поддержки.Уровень 3. Диаграмма компонентов (Component) показывает устройство контейнера.В этом контексте компонент - это группа связанных функций, объединённых четко определенным интерфейсом. В Java или C#, например, это набор классов реализации, стоящих за интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса.
Архитекторы и разработчики видят, из чего состоит каждый контейнер, что представляет собой каждый из компонентов, их обязанности и детали реализации. Другим участникам команды такая диаграмма вряд ли понадобится – их стоит готовить, только если их ценность очевидна. Желательно подумать об автоматизации для долговременной документации.Уровень 4. Диаграмму кода (Code), например, класс UML, можно использовать для изучения отдельных модулей. Не рекомендуется ни для чего, кроме наиболее важных или сложных компонентов.Это дополнительный уровень детализации, который в идеале нужно генерировать автоматически с использованием IDE, UML и других инструментов. Следует рассмотреть возможность отображения только тех атрибутов и методов, которые могут показать на практике некую историю. Даже с относительно небольшой программной системой заманчиво попытаться включить всю историю в одну диаграмму. На практике вам, скорее всего, не хватит места на холсте или информацию загромоздит множество перекрывающихся линий. Если никто не поймет диаграмму, никто не будет ее смотреть.Вместо этого стоит попробовать разделить сложную диаграмму на простые по определенным областям бизнеса, функциям, контексту, взаимодействию с пользователем и т.д. Рабочие инструментыЧтобы создать такую модель, мы используем следующий стек:1. PlantUML – позволяет генерировать UML-диаграммы из текста;2. C4Builder – обеспечивает экспорт в PDF и прочие форматы;3. IDE-плагин – отвечает за автоматизацию и удобное для разработчиков взаимодействие с моделью.Вот как выглядит рабочее окно IDE c возможностью переходить с одного уровня архитектурной абстракции на другой:
Как быстро устаревают диаграммы в C4Из-за иерархической природы каждая диаграмма будет изменяться с разной скоростью.· Контекст системы: в большинстве случаев очень медленно, поскольку описывает ландшафт, в котором работает система.· Контейнеры: обновляется тем чаще, чем больше вы используете микросервисы, бессерверные функции и т.д.· Компоненты. Для любой системы в активной разработке, диаграммы компонентов будут меняться по мере того, как команда добавляет, удаляет или реструктурирует код. Как мы говорили, этот уровень стоит максимально автоматизировать.· Код: диаграммы, например, классов потенциально устареют очень быстро. По этой причине рекомендуется (1) не создавать их вообще или (2) создавать их по запросу с использованием таких инструментов, как ваша IDE.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Simon Brian
===========Похожие новости:
- [Программирование, Анализ и проектирование систем, Совершенный код, Проектирование и рефакторинг, ООП] Метрика Cognitive complexity или простой способ измерить сложность кода
- [Анализ и проектирование систем, IT-инфраструктура, Микросервисы] REST or Events? Choose the right communication style for your microservices
- [Анализ и проектирование систем, Интерфейсы, API] Проектирование интеграции с веб-сервисом
- [Анализ и проектирование систем, Разработка мобильных приложений, Usability, Дизайн мобильных приложений] Запихнуть многоквартирный дом в маленький телефон
- [Разработка веб-сайтов, Анализ и проектирование систем, IT-инфраструктура, API, Софт] gRPC vs REST, что выбрать для нового сервера?
- [Программирование, Анализ и проектирование систем, ООП] Многоликий принцип единственности ответственности
- [Анализ и проектирование систем, Графические оболочки, Работа с 3D-графикой, CAD/CAM] Dassault Systèmes — новые горизонты строительной отрасли
- [Анализ и проектирование систем, Разработка для Office 365, Управление продуктом, Будущее здесь] Как мы в dentsu Link.One строили (часть I-я)
- [Высокая производительность, Анализ и проектирование систем, Промышленное программирование, Распределённые системы] Как проходят архитектурные секции собеседования в Яндексе: практика дизайна распределённых систем
- [Анализ и проектирование систем, Разработка под Android] «Оливье в каждой семьей свой»: или как мы придумали ещё одну многомодульную архитектуру
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_arhitektura_prilozhenij (архитектура приложений), #_proektirovanie_itproduktov (проектирование ИТ-продуктов), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 01-Ноя 05:04
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 8 месяцев |
|
|
Когда мы начали создавать платформу True Engineering, в компании не было единых правил для оформления архитектуры. Разные команды – разные инструменты, разные обозначения и уровни абстракции. Значит, даже подобные решения сравнить между собой не получится, а тому, кто смотрит на архитектуру проекта в первый раз, обычно нужен проводник, который расскажет, что же тут изображено. Мы решили унифицировать подходы с помощью модели С4, которая обеспечивает всестороннее описание программных архитектур.Сама по себе такая задача описания архитектуры, мягко говоря, не новая, и решить её можно несколькими способами:· MS Visio и подобные редакторы – громоздко, малоудобно. Эти средства создавались для иных целей, и это заметно.· UML – эти диаграммы быстро увеличиваются в количестве, довольно скоро их становится сложно поддерживать. К тому же фактически нужно всегда иметь в виду масштаб всей системы.· 4+1 – снова проблемы с поддержкой и масштабом, высокий порог входа для новых участников команды.В C4 многих этих проблем нет. Она объединяет 4 иерархических уровня: (1) Context, (2) Container, (3) Component, (4) Code.  Как можно прочитать на сайте по модели C4, создал её лондонский программный архитектор Саймон Браун (Simon Brown) в рамках своего учебного курса. В программе было упражнение, когда участников просили разработать архитектуру продукта по заданным требованиям. Браун увидел, что нарисовать несколько диаграмм, чтобы выразить замысел, оказалось сложнее, нежели он представлял. И разработал систему для формализованного подхода к архитектуре ПО.Зачем создали модель C4· Чтобы помочь командам описывать архитектуру как при предварительном проектирования, так и при ретроспективном документировании кодовой базы· Чтобы создавать карты кода на разных уровнях детализации – автор приводит в пример Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.· Чтобы дать архитекторам, разработчикам, PM-ам и аналитикам абстрактные модели для работы с архитектурным схемами.Теперь о том, что это за абстракции и на каких уровнях они существуют.Уровень 1. Диаграмма системного контекста (System Context) обеспечивает отправную точку, которая показывает, как программная система вписывается в окружающий ее мир.Здесь описываются функции, которые приносят пользу пользователям. Уровень включает в себя и сам продукт, и другие взаимосвязанные с ними системы.  Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а пользователи, роли, акторы, программные системы. С этой диаграммой будет легко работать бизнес-заказчикам и не-техническим людям.Уровень 2: Как только вы поймете, как ваша система вписывается в общую ИТ-среду, следующий шаг - увеличить масштаб до высокоуровневых строительных блоков. Диаграмма контейнера (Container) показывает общую форму архитектуры, распределение функций и обязанностей.  Не путать с Docker-контейнерами – в C4 контейнер представляет то, что необходимо запустить для работы всего продукта. Например, серверное, мобильное или веб-приложение, клиентская программа, БД, бессерверная функция, shell-скрипт.Каждый контейнер – это отдельно развертываемый объект или среда выполнения, которая зачастую работает в собственном пространстве процессов. Из-за этого связь между контейнерами обычно принимает форму межпроцессного взаимодействия.Такая диаграмма полезна как команде разработчиков, так и службе поддержки.Уровень 3. Диаграмма компонентов (Component) показывает устройство контейнера.В этом контексте компонент - это группа связанных функций, объединённых четко определенным интерфейсом. В Java или C#, например, это набор классов реализации, стоящих за интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса.  Архитекторы и разработчики видят, из чего состоит каждый контейнер, что представляет собой каждый из компонентов, их обязанности и детали реализации. Другим участникам команды такая диаграмма вряд ли понадобится – их стоит готовить, только если их ценность очевидна. Желательно подумать об автоматизации для долговременной документации.Уровень 4. Диаграмму кода (Code), например, класс UML, можно использовать для изучения отдельных модулей. Не рекомендуется ни для чего, кроме наиболее важных или сложных компонентов.Это дополнительный уровень детализации, который в идеале нужно генерировать автоматически с использованием IDE, UML и других инструментов. Следует рассмотреть возможность отображения только тех атрибутов и методов, которые могут показать на практике некую историю. Даже с относительно небольшой программной системой заманчиво попытаться включить всю историю в одну диаграмму. На практике вам, скорее всего, не хватит места на холсте или информацию загромоздит множество перекрывающихся линий. Если никто не поймет диаграмму, никто не будет ее смотреть.Вместо этого стоит попробовать разделить сложную диаграмму на простые по определенным областям бизнеса, функциям, контексту, взаимодействию с пользователем и т.д. Рабочие инструментыЧтобы создать такую модель, мы используем следующий стек:1. PlantUML – позволяет генерировать UML-диаграммы из текста;2. C4Builder – обеспечивает экспорт в PDF и прочие форматы;3. IDE-плагин – отвечает за автоматизацию и удобное для разработчиков взаимодействие с моделью.Вот как выглядит рабочее окно IDE c возможностью переходить с одного уровня архитектурной абстракции на другой:  Как быстро устаревают диаграммы в C4Из-за иерархической природы каждая диаграмма будет изменяться с разной скоростью.· Контекст системы: в большинстве случаев очень медленно, поскольку описывает ландшафт, в котором работает система.· Контейнеры: обновляется тем чаще, чем больше вы используете микросервисы, бессерверные функции и т.д.· Компоненты. Для любой системы в активной разработке, диаграммы компонентов будут меняться по мере того, как команда добавляет, удаляет или реструктурирует код. Как мы говорили, этот уровень стоит максимально автоматизировать.· Код: диаграммы, например, классов потенциально устареют очень быстро. По этой причине рекомендуется (1) не создавать их вообще или (2) создавать их по запросу с использованием таких инструментов, как ваша IDE. =========== Источник: habr.com =========== =========== Автор оригинала: Simon Brian ===========Похожие новости:
Анализ и проектирование систем ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 01-Ноя 05:04
Часовой пояс: UTC + 5