Александр Точин: Описываем сервисы в C4 и Structurizr

• Обсуждение проблем с обновлением Docker.  

• Рассуждения о проекте LIMA и его использовании для коммерческой разработки.  

• Проблемы с настройкой и использованием LIMA в проектах.  

• Приветствие участников и приглашение к вопросам.  

• Подготовка к докладу и обсуждение сложностей.  

• Важность указания точных параметров в Docker-контейнерах.  

• Описание процесса внедрения модели C4 в компанию.  

• Проблемы с выбором инструмента и началом работы.  

• Преимущества использования модели C4 для описания микросервисной архитектуры.  

• Представление Гриши Скобелева и Саши.  

• Тема доклада: описание и документирование архитектур взаимодействия сервисов.  

• Проблемы с отсутствием документации при большом количестве сервисов.  

• Обсуждение различных методов документирования: документы, диаграммы.  

• Проблемы с выбором нотации и инструментов для создания диаграмм.  

• Варианты графических и текстовых инструментов для создания диаграмм.  

• Нотация UML сложна и требует декомпозиции для наглядности.  

• Графическое представление усложняет версионирование и управление изменениями.  

• Текстовое представление проще для отслеживания истории изменений.  

• Модель C4 предлагает упрощенную нотацию UML.  

• Основана на концепции декомпозиции, что позволяет не захламлять диаграммы.  

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

• Контекст диаграмма описывает сервис и его взаимодействия.  

• Контейнер диаграмма показывает компоненты сервиса.  

• Компонентная диаграмма детализирует компоненты сервиса.  

• Диаграмма кода используется для описания кода, но не всегда актуальна.  

• Систем скейп диаграмма показывает все системы и их взаимодействия.  

• Динамическая диаграмма описывает процессы и взаимодействия.  

• Диаграмма развертывания показывает, где развернуты приложения.  

• C4 определяет основные объекты и взаимосвязи.  

• Графические инструменты включают встроенный CLIPS.  

• Текстовые инструменты включают плагин для UML.  

• Автор методологии предлагает использовать инструмент StructureRizer.  

• Позволяет хранить описание систем в одном файле.  

• Отделяет модель от представления.  

• Возможность выгрузки диаграмм в разные форматы.  

• Переход к демонстрации использования C4.  

• Файл WorkSpace.dsl используется для описания диаграмм.  

• Включает корневой элемент, документацию, артефакты и модель.  

• Описывает системы, такие как веб-сайт, сервис пользователей и сервис платежей.  

• Сервис платежей предоставляет API для веб-сайта и реализует логику оплаты.  

• Логика работы с провайдерами реализуется в отдельных сервисах.  

• Группы систем могут быть вложенными.  

• Описание системы включает ключевые слова, название, описание и теги.  

• Пример: веб-сайт, сервис клиентов, бэк-энд и кэш.  

• Описание компонентов системы, таких как бэк-энд приложение, база данных и планировщик.  

• Описание взаимосвязей между системами, например, запросы от веб-сайта к сервису.  

• Указание технологий, таких как JSON.  

• Описание взаимодействия между компонентами, такими как бэк-энд и база данных.  

• Использование инструментов для отображения диаграмм, таких как Structureizer Lite и On Premise.  

• Облачный сервис и консольная утилита для загрузки и выгрузки данных.  

• Пример запуска Structureizer Lite в Docker.  

• Вопрос о хранении WorkSpace: в проекте или отдельно.  

• On Premise как решение для хранения и управления WorkSpace.  

• Документация и диаграммы в формате Markdown.  

• Сервис написан на Java, что позволяет использовать автолауд.  

• Пример диаграммы без автолауда для демонстрации возможностей.  

• Диаграммы для всех сервисов и контекстные диаграммы.  

• Отображаются другие сервисы, взаимодействующие с сервисом платежей.  

• Решение: исключить все взаимосвязи, кроме сервиса платежей.  

• Диаграмма становится более понятной и удобной для восприятия.  

• Использование DXL для настройки представления.  

• Исключение всех взаимосвязей, кроме сервиса платежей.  

• Обновление диаграммы для улучшения восприятия.  

• Kafka скрывает взаимосвязи, что затрудняет понимание диаграммы.  

• Рекомендуется не добавлять инфраструктурные элементы, такие как Kafka.  

• Альтернативное решение: показывать прямые связи между сервисами.  

• Коннекторы к банкам выделены в отдельные системы.  

• Рекомендуется переписать диаграмму, чтобы убрать лишние элементы.  

• Удаление ненужных элементов улучшает читаемость диаграммы.  

• Использование тем и стилей для улучшения внешнего вида диаграммы.  

• Настройка стилей для различных элементов, таких как базы данных и внешние системы.  

• Обновление стилей для улучшения восприятия диаграммы.  

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

• Рекомендации по использованию стилей и тегов для настройки элементов.  

• Возможность вернуться к документации для дополнительных сведений.  

• Использование MD-файлов для записи архитектурных решений.  

• Удобство хранения и просмотра архитектурных решений.  

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

• Обзор инструментов: On Premise, Key, Cloud Service.  

• Использование Docker для запуска сервисов.  

• Создание и управление рабочими пространствами.  

• Использование интерфейса командной строки для загрузки диаграмм.  

• Возможность редактирования и ревью диаграмм.  

• Настройка пользователей и разграничение доступа.  

• Обзор репозиториев на GitHub.  

• Использование DSL для описания систем.  

• Примеры использования аннотаций и процессоров.  

• Ответы на вопросы о лицензии и выборе инструментов.  

• Преимущества текстового описания диаграмм.  

• Удобство изменения диаграмм и их перерисовки.  

• Вопрос о том, кто должен описывать сервисы: аналитик или разработчик, зависит от ситуации.  

• Если сервисов нет, то это может быть аналитик или архитектор.  

• Если сервисы уже есть, то можно попросить аналитика или разработчика описать их.  

• Можно встраивать DXL в другие языки, такие как Kotlin, Kotlin DSL, Java.  

• В DXL есть раздел про скрипты, которые можно добавлять как inline или во внешние файлы.  

• Можно добавить скрипт и ссылку на него, чтобы подтянуть данные.  

• DXL активно развивается, что может приводить к глюкам и изменениям.  

• Документация не всегда актуальна, и некоторые функции могут исчезнуть в новых версиях.  

• Это может создавать неудобства для пользователей, так как изменения могут нарушить работу.  

• Structureizer помогает разработчикам и инженерам лучше понимать контекст и строить системы.  

• Однако, инструмент не всегда подходит для моделирования сложных архитектур.  

• Structureizer ориентирован на сервисное взаимодействие и не учитывает все аспекты архитектуры.  

• Structureizer может тормозить при большом количестве элементов модели.  

• Инструмент не справляется с миграцией и трансформацией архитектуры.  

• Для больших проектов Structureizer может быть неудобен из-за проблем с производительностью.  

• Вопрос о возможности использования Structureizer для других языков, таких как Go.  

• Автор не предлагает, но где-то видел плагин для Go.  

• Существует плагин, который позволяет использовать до структурайзер.  

• Библиотека генерирует все четыре диаграммы из Golang кода.  

• Модель C4 набирает популярность, особенно в индустрии Spotify.  

• Автор активно отвечает на вопросы и помогает пользователям.  

• Вопрос о скрытии компонентов с диаграммы систем контекста был решен.  

• Модель C4 не подходит для описания процессов, лучше использовать BPM.  

• Структура не предоставляет версионируемость для диаграмм.  

• Текстовые файлы можно хранить в Git-репозиториях для контроля версий.  

• В любом программном продукте есть несколько версий, включая проде и деве.  

• Доклад был невероятно интересным и полезным.  

• Благодарности участникам и зрителям за участие и вопросы.  

• Предложение сделать совместную фотографию с приглашенным гостем.