Шпаргалка для тех, кто ещё не понял, что выбрать

Виды нереляционных БД. Какие бывают NoSQL базы данных

Ранее мы писали о реляционных БД, сравнивали их с нереляционными. Познакомимся с NoSQL подробнее. Все ссылки кликабельны, нажмите на название СУБД и откроется статья из Хабра.

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

1️⃣ Ключ-значение (Key-value)
Предназначены для быстрых, почти мгновенных запросов для таких задач как кэш, отображение баланса и т.д.. Высокая скорость осуществляется за счет хранения данных по принципу ключ-значение, и в большинстве случаев благодаря работе в оперативной памяти. Записи хранятся и извлекаются с использованием ключа, который однозначно идентифицирует запись и используется для быстрого поиска данных.
👉 Примеры СУБД: Redis, Memcached, Tarantool.

2️⃣ Документо-ориентированные БД
Могут быть полезны, если нужно хранить много файлов/документов и вы не хотите задумываться о структуре хранения, иерархии, связях. Такие БД имеют структуру дерева: начинаются с корневого узла и может содержать несколько внутренних и листовых узлов.

Листовые узлы содержат данные, которые при добавлении документа заносятся в индексы, это дает возможность даже при достаточно сложной структуре находить путь к искомых данных. В отличие от хранилищ типа ключ-значение, выборка по запросу к документному хранилищу может содержать части большого количества документов без полной загрузки этих документов в оперативную память.
👉 Примеры СУБД: MongoDB.

3️⃣ БД временных рядов (TSDB)
Подходят, если есть упорядоченные по времени данные с временными метками, такие как метрики от инфраструктуры или данные датчиков. Часто используются для осуществления мониторинга различных метрик (будь то загрузка CPU, или показатели работы какого-либо датчика).
👉 Примеры СУБД: Prometheus, InfluxDB, Graphite.

4️⃣ Графовые БД
Применяются, когда нужно анализировать отношения данных, их связи или просто упростить запросы с километровыми Join, имеет смысл использовать графовые базы данных. Данные и их связи представляются как вершины и ребра графа соответственно. Таким способом можно легко представить денежные переводы (для определения различных мошеннических схем), связи в социальной сети и граф общения между операторами сотовой сети.
👉 Примеры СУБД: Neo4J.

5️⃣ Поисковые БД (Search Engines)
Подходит, если вам необходимо осуществлять поиск по большим объемам данных, особенно неструктурированным, как пример поиск по нескольким терабайтами логов.

Поиск по текстам работает на основе индексирования. Каждому слову/лемме/n-грамме присваивается индекс. Затем формируется структура вроде таблицы, где строки являются документом, а столбцы индексами. Поиск по индексу существенно быстрее, чем по совпадению по словам в документах.
👉 Примеры СУБД: Elasticsearch.

6️⃣ Объектно-ориентированные БД
Здесь информация представлена в виде объектов, прямо как в ООП. Объектно-ориентированные базы данных появились как способ нативной коммуникации кода написанного с использованием объектно-ориентированных языков с базой данных.
👉 Примеры СУБД: Db4o.

7️⃣ Колоночные БД (column family store)
Колоночные NoSQL-базы хранят данные по столбцам, а не по строкам, как в реляционных БД. Это упрощает добавление и удаление свойств, а также позволяет работать с данными без жесткой схемы. Колоночные БД быстро и экономно обрабатывают большие объемы информации для анализа, так как выгружают только нужные значения из столбцов.
👉 Примеры СУБД: Cassandra, Clickhouse.

📎 Ещё полезные материалы
1. Виды баз данных. Большой обзор типов СУБД
2. Базы данных: большой обзор типов и подходов. Доклад Яндекса
3. Модели данных в NoSQL
4. Использование memcached и Redis в высоконагруженных проектах
5. Как базы данных «ключ-значение» обеспечивают производительность и масштабируемость без границ
6. SQL и NoSQL. Правда ли одно лучше другого?

#бд

🏄🏻‍♂️ Балансировка нагрузки. Основные принципы

Балансировка нагрузки — это распределение трафика и задач между серверами. Сначала все компоненты веб-приложения могут быть на одном сервере, но потом его мощности может не хватить. Тогда можно улучшить сервер, добавить CPU/RAM (вертикальное масштабирование) или разделить задачи на несколько серверов (горизонтальное масштабирование).

В случае горизонтального масштабирование появляется несколько серверов, которые работают над одной задачей. Когда пользователь отправляет запрос, какой именно сервер должен взять на себя задачу обработки запроса? Именно для этого и нужна балансировка нагрузки.

✅ Что даёт балансировка нагрузки

➕ Отказоустойчивость. Если один сервер откажет, балансировщик распределит трафик между остальными элементами инфраструктуры.

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

➕ Защита от DDoS-атак. Ее обеспечивает задержка ответа, когда фоновые серверы не видят клиента до подтверждения по TCP.

Три уровня распределения нагрузки

1️⃣ Сетевой. Балансировка осуществляется по следующему принципу: нужно сделать так, чтобы за один конкретный IP-адрес сервера отвечали разные физические машины. К сетевому уровню относятся решения, которые не терминируют на себе пользовательские сессии. Они просто перенаправляют трафик и не работают в проксирующем режиме. На сетевом уровне балансировщик просто решает, на какой сервер передавать пакеты. Сессию с клиентом осуществляет сервер.

2️⃣ Транспортный (L4). Клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который и будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами: путём простого кругового перебора, путём выбора наименее загруженного сервера из пула и т.п.

3️⃣ Прикладной (L7). В отличие от транспортного уровня, он анализирует клиентские запросы и перенаправляет их на разные серверы в зависимости от характера запрашиваемого контента. Примером L7-балансировщика является pgpool, который распределяет запросы к PostgreSQL по их содержанию: чтение — один сервер, запись — другой.

🆚 Балансировка или проксирование?

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

Алгоритмы балансировки

🔹 Round Robin: запросы распределяются по кругу между всеми доступными серверами, без учета их загрузки или других параметров. Это самый простой и равномерный метод, но он не подходит для ситуаций, когда сервера имеют разную мощность или специализацию.

🔹Weighted Round Robin: запросы распределяются по кругу между всеми доступными серверами, но с учетом их веса, который отражает их мощность или приоритет. Это позволяет отправлять больше запросов на более производительные сервера.

🔹Least Connections: запросы направляются на тот сервер, который наименее загружен в данный момент. Это позволяет избегать перегрузки одного сервера.

🔹Least Response Time: запросы направляются на тот сервер, который имеет наименьшее суммарное время ответа. Это позволяет учитывать не только загрузку сервера, но и скорость сети.

🔹Sticky Sessions: запросы одного и того же клиента будет передаваться на один и тот же сервер. Если закреплённый за конкретным адресом сервер недоступен, запрос будет перенаправлен на другой сервер.

📎 Ссылки
1. Статья от Selectel
2. Видео
3. Алгоритмы балансировки нагрузок
4. Введение в современную сетевую балансировку и проксирование
5. Как Контур балансирует нагрузку в микросервисах
6. Балансировка нагрузки в Kubernetes

#инфраструктура

Шпаргалка по выбору правильной СУБД в продолжение к посту про типы нереляционных БД.

Источник

#бд

От монолита к микросервисам. Эволюционные шаблоны для трансформации монолитной системы

✍️ Автор: Сэм Ньюмен
📅 Год: 2021
🔤 Язык: русский

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

Обзор книги

#архитектура #микросервисы #проектирование

🎙 Бесплатные подкасты из Радио "Аналитик"

Скачать любой из подкастов или весь сборник целиком можно по ссылке (Яндекс Диск).

Список подкастов

1. О развитии навыков ИТ-аналитика с Александром Чавалах

2. О работе с изменениями с Алёной Ивахновой

3. О необходимых для аналитика hard skills с Дмитрием Летяго

4. О работе с задачами по адаптации типового решения под требования заказчика с Татьяной Рыловниковой

5. Об основах работы с данными с Владимиром Ловцовым

6. О мышлении и коммуникативных навыках с Гюльнарой Антроповой

7. Об управлении обеспечением предприятий с Дмитрием Кучмой

8. Об обратной связи и её месте в развитии аналитика с Артёмом Пластининым

9. О ванильном мороженом и обучении аналитиков 1С с Анастасией Штей

10. О консалтинге в сфере 1С с Алексеем Бояршиновым

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

12. О командной работе и построении эффективных коммуникаций с Маргаритой Маковеевой

13. О книге Карла Вигерса "Разработка требований к программному обеспечению" с Александром Байкиным

14. О когнитивных искажениях, сервисе UX CORE и проекте KeepSimple c Вольфом Алексаняном

15. О текстах в интерфейсах с Александром Марфициным

16. Об ожиданиях предпринимателей от автоматизации с Артёмом Вахрушевым

17. Об ожиданиях от автоматизации в сферах foodtech и e-com с Павлом Вепревым

18. О мифах, которые рождаются вокруг продуктов с Алексеем Чернышовым

19. О возможностях 1С для создания полезных отчетов с Матвеем Серёгиным

20. Про первый опыт публичного выступления с Ольгой Зубковой

21. Про путь от первого выступления до первого места в топе лучших докладов с Павлом Громовым

22. Про ожидания и реальность офлайн выступлений с Дмитрием Макаровым

23. О планировании с Владимиром Завертайловым и Екатериной Мамонтовой

24. Про интеграции с Артуром Белопольских

25. О пробелах в знаниях, недостающем опыте и новых вызовах для аналитиков из сферы 1С с Еленой Ивановой

26. Про решение проблем с Анастасией Московкиной

27. Про фасилитацию и фасилитирующее лидерство в ИТ с Алексеем Таченковым

#подборка

📝 Задачи для системных аналитиков из конкурса IT_One Cup 2022 с решениями

По ссылкам ниже можно собственноручно прорешать задания и загрузить решение — проверка автоматическая. Требуется зарегистрировать аккаунт на all cups.

Ознакомительный раунд.
1. Задача А (Камни) — решение
2. Задача B (Почта) — решение

Квалификационный раунд
1. Задача А (Авария)
2. Задача B (Кредиты)
3. Задача C (Интеграция)

Заключительный раунд: ссылка на задачу и решение от победителя конкурса прикрепляем (.pdf)

➕ Ещё соревнования:
1. IT’s Tinkoff Solution Cup (с решениями)
2. Sovcombank Challenge 2021 (Системный анализ)

Если вы знаете, какие ещё весёлые конкурсы есть для системных аналитиков, пожалуйста, напишите в комментариях ⬇️

#развитие

Agile и Waterfall: главное о методологиях разработки ПО

Разделение всех методологий на Agile и Waterfall — это общепринятый способ классифицировать подходы к организации процесса разработки ПО.

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

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

✅ Преимущества Waterfall

1. Фиксированный бюджет и сроки, так как всё фиксируется на этапе составления ТЗ

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

❌ Недостатки Waterfall

1. Отсутствие гибкости. В проект нельзя вносить изменения. Если на каком-то из этапов возникнут проблемы, изменятся требования или станет ясно, что что-то не учли, придётся начинать сначала.

2. Риски. Если на каком-то этапе возникнут ошибки или недочеты, они могут быть обнаружены только в конце проекта, когда будет поздно

3. Отсутствие обратной связи. Меньше обратной связи – меньше уверенности, что мы делаем то, что действительно нужно

Где можно применять водопадную модель

● Несложные проекты, где объём работ можно легко определить и сформулировать в ТЗ.
● Проекты с очень строгими требованиями к бюджетам и срокам.

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


🔁 Agile — это семейство гибких методологий управления проектами.

Вся суть Agile содержится в четырёх пунктах его манифеста:

1️⃣ Люди и их взаимодействие важнее процессов и инструментов проектного управления.
2️⃣ Рабочее программное обеспечение (результат проекта) важнее всеобъемлющей документации.
3️⃣ Сотрудничество с клиентами важнее переговоров по контракту.
4️⃣ Реагирование на изменения важнее следования плану.

К Agile относят Scrum, Kanban, Lean, XP, FDD, TDD, SoS, LeSS, SAFe, AgilePM.

В Agile проект делится на небольшие итерации или спринты (примерно 2 недели). Каждая итерация имеет какой-либо результат – готовую функциональность. Клиент участвует в процессе разработки и может давать свою обратную связь по каждой итерации. Продукт постоянно улучшается и адаптируется к изменяющимся требованиям.

✅ Преимущества Agile

1. Гибкость к изменениям и скорость. Например, если конкуренты выпустили новую функцию, её можно быстро разработать в уже начатом проекте.

2. Риски ниже — прямо в процессе команда получает обратную связь от пользователей. А если какая-то итерация растянется, следующую можно будет адаптировать под изменившиеся сроки и условия.

3. Ориентация на людей и команду даёт большую вовлечённость в проект.

❌ Недостатки Agile

1. Сложность внедрения. Его нужно уметь использовать. С умом. К тому же, люди часто привыкают к текущему способу работы и не всегда приветствуют изменения

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

3. Заспамленность созвонами. Вытекает из первого пункта в случае ошибок при внедрении. Однако забитый бессмысленными встречами календарь – это бич не только аджайла. Проблема шире, чем просто подход к разработке ПО.

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

📎 Материалы
1. Битва титанов: Waterfall VS Agile
2. Agile и «водопад». Сравнение подходов
3. Управление проектом по Agile методике
4. Об оценках сроков в разработке ПО
5. Гибридное управление проектами: как смешать модный Agile с традиционным проектным менеджментом

О минусах Agile
1. Scrum ужасен
2. Обратная сторона Agile
3. Как правильно имитировать Agile?

#управление_проектами

Инженерия требований

✍️ Авторы: Халл Элизабет, Джексон Кен, Дик Джереми
📅 Год: 2005
🔤 Язык: русский
📚 Объём: 240 стр.

Авторы подробно объясняют роль системной инженерии в решении разного рода задач по созданию систем. Вот главные моменты:

▪️ внимание к разъяснению важности системной инженерии для эффективного решения проблем создания систем
▪️ описание основных представлений, используемых при моделировании систем, включающее краткое описание языка UML
▪️ анализ взаимосвязи между требованиями и моделированием
▪️ описание многоуровневого процесса инженерии требований, включая особенности этого процесса в области проблем и решений
▪️ подробное разъяснение важной концепции глубокой прослеживаемости
▪️ актуализация обзора инструмента управления требованиями DOORS

✅ Плюсы книги:

1. практически нет «воды», всё изложено чётко и понятно
2. информации много, практически вся она полезная

➖ Минусы книги:

1. для неискушённого читателя и начинающего разработчика книга может показаться сложной

#требования

А у вас какие попугаи обитают?

🐞🔍 Тестирование. Основные понятия

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

💠 Основные виды тестирования

По запуску кода
● Статическое тестирование — тестирование без фактического выполнения кода
● Динамическое тестирование — не может быть осуществлено без запуска программного кода приложения.

По доступу к коду
● Белый ящик – с использованием доступа к исходному коду
● Чёрный ящик – без использования доступа к исходному коду

По уровню тестирования
● Модульное – проводится над отдельным компонентом системы
● Интеграционное – проверка взаимодействия нескольких компонентов или систем
● Системное – показывает, соответствует ли готовая система функциональным и нефункциональным требованиям
● Приёмочное (UAT) – выполняется самим заказчиком

По степени автоматизации
● Ручное
● Автоматизированное

По целям тестирования различают функциональное и нефункциональное тестирование. К нефункциональному тестированию относят:
● Нагрузочное тестирование – проверка поведения системы при плановой повышенной и пиковой нагрузке
● Стрессовое тестирование – проверка работы системы в критических условиях
● Тестирование удобства использования (usability testing)
● Тестирование безопасности
● Регрессионное тестирование — повторное тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.

Тестовые стенды
➖ Среда разработки (Dev) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
➖ Среда тестирования (Test) – среда, в которой работают тестировщики
➖ Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом систем
➖ Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
➖ Продакшн среда (Prod Env) – среда, в которой работают пользователи.

Этапы тестирования
1️⃣ Анализ требований – позволяет выяснить, какие возможные сложности могут возникнуть при тестировании. Также на этом этапе можно выявить возможные несоответствия или недостаточно ясные требования, которые требуют уточнения у разработчиков или заказчика
2️⃣ Планирование тестирования – выбор методов тестирования, определение ресурсов, сроков
3️⃣ Тест-дизайн – разработка тест-кейсов. Тест-кейс — это алгоритм действий, которые требуется совершить для проверки работы системы. Может иметь следующие атрибуты: ID, название, предусловия, шаги, ожидаемый результат, фактический результат, статус
4️⃣ Подготовка к тестированию – включает создание тестового окружения, подготовку тестовых данных, написание автотестов, деплой приложения на тестовом стенде
5️⃣ Выполнение тестирования – Сначала выполняется интеграционное или даже сразу системное тестирование, зависит от специфики тестирования в конкретной компании. Модульное тестирование обычно выполняется разработчиком при написании кода с помощью unit-тестов
6️⃣ Формирование результатов – подготовка отчёта о тестировании, содержащего информацию о результатах выполнения тест-кейсов и о выявленных дефектах

📎 Материалы
1. Фундаментальная теория тестирования
2. Как устроен процесс тестирования
3. Какие бывают этапы и виды тестирования
4. Как писать тест-кейсы
5. Большой учебник по тестированию
6. Курс по тестированию The 100-Year QA-Textbook — полезно и для аналитиков
7. Видео по видам тестирования

#тестирование #развитие

🚆 Релизный процесс. Кратко

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

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

Артефакты релиза можно условно разделить на две категории:

🔹 Релизные объекты – это физические или логические компоненты, которые составляют релиз, например, исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.

🔸 Документация релиза – это документы, которые описывают релиз. Сюда входят: Release Notes (описание того, что изменилось), план релиза протокол тестирования, отчёт о релизе и т.д.

Управление релизами охватывает все этапы от разработки и тестирования до развертывания.

Этапы релиза могут быть разными, но обычно включают в себя следующие:

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

2️⃣ Сборка релиза. На этом этапе происходит создание и упаковка релизных объектов, таких как исходный код, исполняемые файлы, конфигурационные файлы, базы данных и т.д.

3️⃣ Приемочное пользовательское тестирование (UAT). Финальное тестирование, выполняемое перед выпуском в продуктив. После проведения тестирования руководство вместе с разработчиками принимают окончательное решение о выпуске продукта.

4️⃣ Развертывание релиза. На этом этапе код собирается в исполняемый файл или пакет, который может быть развернут на сервере или облачной платформе. Для этого могут использоваться различные инструменты и методы, такие как непрерывная доставка, контейнеризация, автоматизация и т.д. Цель этого этапа — упростить и ускорить процесс развертывания и обеспечить его надежность и безопасность.

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

📎 Материалы
1. Всë, что вам нужно знать об управлении релизами
2. Релизный цикл ПО для самых маленьких
3. Автоматизация процесса релиза (+ видео)
4. От пул-реквеста до релиза. Доклад Яндекс.Такси
5. Рецепт гладкого релиза: PMy на заметку
6. Управление релизами, когда и зачем нужно?
7. Как мы автоматизировали процесс генерации Release Notes — опыт МТС
8. Чек-лист: что нужно было делать до того, как запускать микросервисы в prod
9. Релизный поезд. Доклад Яндекса

#devops #управление_релизами

🟦 Нотация C4. Подборка материалов

С4 – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: Context, Container, Component, Code – отсюда и название.

1️⃣ Диаграммы контекста (Context) – показывают систему в масштабе ее взаимодействия с пользователями и другими системами. Детали здесь не важны, так как это уменьшенное изображение, показывающее общую картину системного ландшафта. В центре внимания не технологии, протоколы и другие низкоуровневые детали, а люди и системы. С диаграммой этого уровня могут работать “люди из бизнеса”.

2️⃣ Диаграммы контейнеров (Container) – показывают, как система разделена на отдельные контейнеры, которые работают в своих средах выполнения и взаимодействуют друг с другом и с внешним миром. Контейнеры могут быть приложениями, базами данных, файловыми системами, скриптами и другими элементами, необходимыми для работы системы. Диаграмма контейнеров помогает понять, какие технологии используются в системе, как она устроена и как она обслуживает пользователей и другие системы.

3️⃣ Диаграммы компонентов (Component) – показывает устройство контейнера. Здесь компонент – это группа связанных функций, объединённых четко определенным интерфейсом. Все компоненты не являются отдельно развертываемыми единицами и обычно выполняются внутри контейнера в одном и том же пространстве процесса. Целевая аудитория диаграмм уровня Component – разработчики и системные архитекторы.

4️⃣ Диаграммы кода (Code) – создаются по запросу и показывают низкоуровневую реализацию компонентов. Рекомендовано использовать UML Class diagram/Entity relationship diagram и генерировать эти диаграммы автоматически.
Пример используемых инструментов для уровня Code:
▫️ PlantUML – позволяет генерировать UML-диаграммы из текста;
▫️ C4Builder – обеспечивает экспорт в PDF и прочие форматы;
▫️ C4-PlantUML — плагин для IDEA.

Главные преимущества C4

✅ Унифицированный способ рисовать архитектурные схемы. В отличие от “нотации” boxes and lines, когда каждый рисует, как хочет и непонятно что, модель C4 позволяет улучшить читаемость диаграмм благодаря формализации использования элементов и связей.

✅ Нужная степень детализации. Модель позволяет выбрать нужный уровень детализации вместо того, чтобы попытаться запихнуть все системы и сервисы в одну схему. Это похоже на Google Maps, где можно увидеть целые страны, прежде чем опуститься до области, города и отдельного дома.

⛔️ Недостатки C4

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

➖ Модель не даёт чётких критериев по выделению контейнеров и компонентов. Могут возникать споры, например, по поводу отнесения базы данных к уровню Context или к уровню Component.

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

➖ Модель не учитывает изменения в архитектуре во времени и не позволяет отображать различные варианты и сценарии.

📎 Материалы

🌐 Официальный сайт

📄 Статьи
1. Как описать архитектуру продукта по нотации C4 — теория (вариант 1)
2. Как описать большую систему в нотации С4 — теория (вариант 2)
3. Аналитик и архитектура: UML-диаграммы для модели C4 — статья от Babok School
4. Описание архитектуры системы с помощью C4 model — взгляд разработчика
5. Опыт составления HLD-документации по нотации C4

⏯️ Видео
1. Визуализация архитектуры C4 model / Максим Пальчиков
2. Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
3. C4 models as code — Simon Brown

🎓 Бесплатный курс

#проектирование #архитектура #подборка

P of EAA: Patterns of Enterprise Application Architecture
(Шаблоны корпоративных приложений)

✍️ Автор: Мартин Фаулер
📅 Год: 2016
🔤 Язык: русский
📚 Объём: 548 стр.

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

#проектирование