БАЗА ЗНАНИЙ по системному анализу 🧠

Все посты из канала за всё время разложены по полочкам в едином месте — базе знаний 🤓

Наша цель — сделать кладезь знаний системного аналитика 🧠

Какие плюшки вас ждут:

🗂 Все знания в едином месте: кратко, ёмко, без воды и с подборками полезных материалов 🔥

🔎 Удобный поиск и навигация: все наши конспекты структурированы по группам навыков СА и есть поиск по тексту — вы не утоните в тоннах воды и часах гуглинга

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

📝 Контент на заказ бесплатно: хотите материал на конкретную тему? Любой покупатель может оставить запрос, и мы сделаем обзор с исчерпывающей подборкой материалов абсолютно бесплатно!


➡️ Приобрести вечный доступ к постоянно обновляемой Базе знаний по цене айтишниой книги можно тут: analitik.me — всего 4900 ₽

❗️После успешной оплаты нажмите кнопку Вернуться в магазин, чтобы получить ссылку на закрытый канал (он нужен для авторизации). Если случайно закрыли, ссылка придёт вам на почту.

Если нет карты РФ и по любым другим вопросам можно писать сюда: @radale

P.S. каналы @sys_sa и @lib_analyst продолжают работу в прежнем формате

✍️ Распределенные системы: архитектурные паттерны и стили

В распределённой системем различные компоненты работают вместе, при этом физически разнесены

Характеристики

💙нет центрального управляющего узла
💙узлы взаимодействуют через сеть
💙параллельное выполнение задач на разных узлах
💙отказоустойчивость: работа при отказах отдельных узлов
💙масштабирование: доабвление узлов для увеличения мощности
💙автоматическое перераспределение ресурсов в зависимости от нагрузки
💙адаптация к разным архитектурам / технологиям

Виды

⚪️Вычислительные: распределённые ресурсы для вычислительных задач (пример: кластеры для обработки больших данных)
⚪️Хранилища данных: распределяют данные между несколькими узлами (Cassandra, Яндекс.Cloud)
⚪️Файловые системы: доступ к файлам через распределённую сеть (Virtuozzo Storage, HDFS)
⚪️БД: на нескольких узлах для согласованности и доступности данных (Tarantool, CockroachDB)
⚪️Очереди сообщений (Kafka, RabbitMQ)
⚪️Системы управления (Kubernetes)


Примеры архитектурных стилей распределённых систем

Напомним, архитектурный стиль — общий принцип, а паттерн — конкретная реализация этого принципа

✨Клиент-сервер: центральный сервер обслуживает запросы клиентов
➡ Пример: веб-приложения, где браузер взаимодействует с веб-сервером

✨Микросервисы: система делится на независимые сервисы. Взаимодействуют через API и могут разрабатываться, развёртываться и масштабироваться независимо
➡ платформа для доставки еды, где микросервисы управляют заказами, платежами и клиентским профилем отдельно

✨Одноранговая (P2P): все узлы равноправны, каждый может быть как клиентом, так и сервером
➡ торрент-сети (файлы передаются без центрального сервера)

✨Многоуровневая: система разделена на слои (представление, логика, данные), каждый выполняет свою функцию
➡ веб-приложения с фронтендом, бекендом и БД на разных серверах

✨Событийно-ориентированная архитектура (EDA): система реагирует на события, что позволяет асинхронное взаимодействие
➡ онлайн-магазин: событие "новый заказ" отправляется в очередь. Службы (склад, оповещения) реагируют на события и выполняют действия (упаковка товара, отправка уведомлений)

✨Сервис-ориентированная архитектура (SOA): взаимодействие между различными сервисами, которые выполняют отдельные бизнес-функции
➡ корпоративные системы, где отдельные сервисы отвечают за учет, CRM, логистику и др.


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

🔹CQRS: разделение операций чтения и записи для повышения производительности и масштабируемости
💙 интернет-магази: обработка заказов и поиск товаров работают независимо

🔹Service Mesh: управление сетевыми взаимодействиями микросервисов для маршрутизации, мониторинга и безопасности
💙 Istio, Linkerd: управление трафиком между микросервисами

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

🔹Двухфазная фиксация (2PC): протокол для атомарности транзакций. Состоит из двух фаз — подготовка и фиксация, что гарантирует согласованность данных.
💙 банковская система: перевод средств между счетами требует согласования изменений в нескольких БД


Недостатки распределенных систем

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


Связь с CAP-теоремой

CAP-теорема относится только к распределённым системам.
Утверждает, что система может одновременно гарантировать только две из трёх характеристик:
💙консистентность
💙доступность
💙устойчивость к разделению


📎 Материалы
1. Лекция 1: Введение в распределенные системы
2. Централизованные vs децентрализованные vs распределенные системы
3. Основы Распределенных Систем
4. Консистентность и ACID-гарантии в распределенных системах хранения данных
5. Топ-5 архитектурных паттернов для распределённых систем

🧑‍🎓 Больше полезного в базе знаний по системному анализу

#архитектура

🔵 Нормальные формы баз данных

Напомним, нормализация — организация данных в таблицах БД так, чтобы:
🟠устранить избыточность данных (уменьшаеся объем хранения, ниже риск рассинхронизации и проще управление)
🟠улучшить целостность данных (поддерживается правильные связи, меньше ошибок)
🟠уменьшить их дублирование (оптимизация структуры, лучше производительность)


Процесс нормализации

Таблицы делятся на мелкие, связанные по смыслу, а между ними создаются связи.
Происходит шаг за шагом. В результате БД приводится к нормальным формам (NF)


Нормальные формы (NF) – требование к структуре таблиц реляционных БД
🟣чем выше NF, тем меньше лишних и зависимых данных -> БД работает быстрее и точнее , но усложняется её структура
🟣БД считается нормализованной после достижения третьей нормальной формы.
NF выше третьей нужны для устранения более сложных зависимостей
🟣чтобы таблица была в нужной NF, она сначала должна соответствовать всем предыдущим формам.


😈Первая нормальная форма (1NF)
Требования:
➖каждое поле должно содержать атомарные значения (неделимые на части).
➖отсутствие повторяющихся групп данных

Пример:
➡️ до: таблица с полем "телефоны", где у одного человека несколько телефонов в одной ячейке.
⬅️ после: каждый телефон записан в отдельной строке

😈нормальная форма (2NF)
частичные зависимости разделяются на новые таблицы.
➖все столбцы должны зависеть полностью от первичного ключа, а не только от его части (если первичный ключ состоит из нескольких полей)

➡️ до: в таблице заказов хранятся поля "имя клиента", "адрес клиента" и "ID заказа". Эти данные повторяются для каждого заказа клиента, что приводит к избыточности.
⬅️ после: эти данные выносятся в отдельную таблицу "клиенты", чтобы убрать дублирование в каждом заказе одного клиента

😈нормальная форма (3NF)
➖все столбцы зависят только от первичного ключа
(т.е. устранение транзитивных зависимостей: когда второй атрибут зависит от первого, а третий - от второго)

➡️ до: в таблице товаров есть поле "город" и "почтовый индекс".
"почтовый индекс" зависит от "города", а не от товара.
⬅️ после: данные разделяются: "город" и "почтовый индекс" в отдельную таблицу адресов, а "товар" — в другую

🔣Нормальная форма Бойса-Кода (BCNF) — более строгая версия 3NF, решает некоторые её недостатки
➖каждый атрибут, от которого зависят другие поля в таблице, однозначно идентифицировал запись (был кандидатным ключом)

😈нормальная форма (4NF)
➖удаляются многозначные зависимости (несколько значений зависят от одного атрибута)

➡️ до: в таблице "студенты" есть поля "курсы" и "хобби". Один студент может учиться на нескольких курсах и иметь несколько хобби, что приведёт к дублированию данных.
⬅️ после: зависимости разделяют на отдельные таблицы: одна для курсов, другая для хобби, чтобы избежать повторений

😈нормальная форма (5NF)
➖удаляются JOIN- зависимости, данные не могут быть разделены на более мелкие части без потери информации.
Предотвращает аномалии при соединении данных из множества таблиц.

➡️ в системе договоров один договор может включать несколько услуг от разных компаний.

😈нормальная форма (6NF)
редко используется, дальнейший шаг нормализации для поддержки временных данных и их зависимостей

➡️ когда данные меняются во времени (например, истории изменений зарплат), чтобы каждая запись была уникальной и не дублировалась


📎 Материалы
1. Нормализация отношений. Шесть нормальных форм
2. Как привести данные в форму: что такое нормализация и зачем она нужна
3. Нормализация и нормальные формы (описание 1-6 NF)
4. Нормализация СУБД: пример базы данных 1NF, 2NF, 3NF
5. Первая НФ (1NF) базы данных
6. Вторая НФ (2NF) базы данных
7. Нормальные формы: третья и Бойса-Кодда
8. Четвертая НФ (4NF) базы данных
9. Пятая НФ (5NF)
10. Шестая НФ (6NF) базы данных

📚Книги
1. Технологии проектирования баз данных -- Дмитрий Осипов (Глава 6-7)
2. Основы технологий баз данных — Новиков Б. А. / Б. А. Новиков, Е. А. Горшкова, Н. Г. Графеева; под ред. Е. В. Рогова
3. Основы баз данных — Кузнецов (Лекции 7-9)

#бд

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

🔵 Интеграция через общую базу данных

Рассмотрим еще один способ интеграции, менее популярый: интеграция через общую БД
Этот подход имеет свои преимущества, но не всегда является лучшим выбором из-за сложностей с согласованностью данных и производительностью

При интеграции через общую БД несколько систем используют одну и ту же БД для обмена данными

Принцип работы

🤤 все подключено к одной БД, ее используют для обмена информацией
🤤 системы читают и пишут данные напрямую через SQL-запросы или с помощью API, коннекторов

Особенности

💙системы должны согласовать структуру данных (схему БД), чтобы все понимали формат и правила работы с данными
💙одновременный доступ разными системами может приводить к блокировкам
Чтобы избежать используются механизмы синхронизации транзакций
💙изменения сразу видны другим системам


Способы интеграции

😮‍💨 Коннекторы (Database Connectivity, DBC)

Например, ODBC/JDBC-драйверы.
🟧JDBC — интерфейс для подключения Java-приложений к БД, позволяет выполнять SQL-запросы
🟧ODBC — универсальный интерфейс для подключения приложений на разных языках к БД, также использует SQL-запросы

Работают как посредники между приложением и БД.
Принимают запросы от приложения, преобразуют их в SQL-команды для БД, выполняют запросы и возвращают результат

😮‍💨 API

Приложения взаимодействуют с БД через REST или SOAP API
Отправляют HTTP-запросы, которые преобразуются в SQL-запросы внутри базы

😮‍💨 Прямое подключение

🤤 через SQL-запросы
Прямое подключение через SQL-запросы: приложение отправляет SQL-команды напрямую в базу данных по сети (например, через TCP/IP), без использования посредников.

🤤 через сетевые драйверы
Используются драйверы для установления связи с БД по сети (например, TCP/IP), затем приложение отправляет SQL-запросы напрямую

В обоих случаях идет работа с БД напрямую.
Но сетевые драйверы (например, для PostgreSQL или MySQL) обеспечивают управление сетевым соединением

🤤 через представления

Создаются виртуальные таблицы (представления), которые объединяют данные из нескольких таблиц.
🟧приложения не изменяют основные таблицы
🟧они выполняют SQL-запросы к представлениям, как к обычным таблицам
🟧выдаются права на чтение нужных представлений


Когда использовать общую БД

💙интеграция внутренних систем (например, системы из одной корпоративной платформы: ERP, CRM и т.д.)
💙для объединения данных из разных источников
💙надо сразу видеть изменения в системе
💙для минимизации повторного хранения данных
💙для интеграции Legacy-систем или самописных систем


Пример работы

В компании несколько систем: интернет-магазин, система управления складом и бухгалтерия

⏩ интернет-магазин: клиенты оформляют заказы, данные сразу записываются в общую Д
⏩ система управления складом: получает информацию о заказах из той же БД и обновляет количество товара на складе
⏩ бухгалтерия: автоматически подтягивает данные о продажах из общей БД для учёта финансов

Все системы работают с одной БД, не нужно синхронизировать данных между ними, данные актуальны во всех системах


Недостатки

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


📎 Материалы

1. Основы интеграции информационных систем
2. Архитектура приложений и интеграций: гайд по основным понятиям простыми словами
3. Современные стандарты информационного взаимодействия систем
4. Простой пример JDBC для начинающих
5. Две альтернативы JDBC
6. PostgreSQL и JDBC выжимаем все соки
7. Доктор, у меня легаси: лечим устаревшие ИТ-системы
8. Legacy-системы
9. Общая информация о ODBC и Connector/ODBC
10. Почему интеграционная бд это отстой

#интеграции

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

▶️ ER-диаграмма (Entity-Relationship Diagram)

ER-диаграмма (Entity-Relationship Diagram, ERD) — диаграмма "сущность-связь",  которая применяется для:
🔘проектирования БД, описания процессов и бизнес-логики
🔘моделирования структуры данных и их связей в системах или приложениях
🔘документирования требований

Состоит из элементов

⏩Сущности — объекты (например, пользователь, заказ)
⏩Атрибуты — характеристики сущностей (имя, дата заказа)
⏩Связи — отображают, как сущности связаны друг с другом ( пользователь делает заказ)


Типы связей между сущностями

🟡Один-к-одному (1:1): каждая запись в одной сущности соответствует одной записи в другой
🟡Один-ко-многим (1:M): одна запись в сущности соответствует нескольким записям в другой
🟡Многие-ко-многим (M:M): каждая запись в одной сущности связана с несколькими записями в другой, и наоборот


Пример ERD для интернет-магазина

*️⃣Сущности: пользователь, заказ, товар

*️⃣Атрибуты:
— пользователь: ID, имя, email
— заказ: ID заказа, дата, сумма
— товар: ID товара, название, цена

*️⃣Связи:
— пользователь делает заказ (один пользователь может сделать много заказов — связь "один ко многим")
— заказ содержит товары (один заказ может включать много товаров — связь "многие ко многим")


Уровни ER-диаграмм

ER-диаграммы делятся на 3 уровня в зависимости от уровня детализации

🟡Концептуальный: описывает общую структуру данных без технических деталей.
Показывает, какие сущности и связи существуют
➡ применяется на стадии сбора требований и анализа для обсуждения с бизнесом и заказчиками.

🟡Логический: уточняет атрибуты сущностей и типы связей.
Детализирует модель, но не привязан к конкретной СУБД
➡ используется на этапе уточнения требований и согласования структуры данных

🟡Физический: описывает, как данные будут реализованы в БД, с учётом таблиц, индексов, первичных и внешних ключей.
➡ используется на этапе реализации и разработки БД


Нотации ERD

ER-диаграмма —  визуальная модель или схема,
а нотации — методы, с помощью которых она строится

🟡Нотация IDEF1X: фундаментальная, используется для физического уровня, ориентирована на стандарты реляционных БД. Редко используется на практике
⏩сущности: прямоугольники с именем сущности
⏩связи: линии с символами "лапками" для связи один-ко-многим, "палка" для связи один-к-одному
⏩атрибуты: внутри прямоугольников сущностей

🟡Нотация Чена: классическая нотация, часто используют для концептуальных моделей
⏩сущности: прямоугольники
⏩связи: ромбы, соединены линиями с сущностями
⏩атрибуты: овалы, соединены линиями с сущностями

🟡Нотация Мартина («воронья лапка»): компактнее нотации Чена, используют для логического уровня, когда нужно описать все атрибуты сущностей

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


Отличия от других инструментов

🔵UML-диаграммы классов

Нужны для моделирования объектов и их поведения в объектно-ориентированном программировании, а не для реляционных БД
⏩UML отражают методы (функции) классов
⏪ERD показывают только структуру данных и их взаимосвязи

🔵BPMN

Моделируют бизнес-процессы и последовательность действий, а не данные
⏩BPMN отображает шаги процесса и участников
⏪ERD — только структуру данных и их отношения внутри системы


📎 Материалы

1. Сущности и связи: как и для чего системные аналитики создают ER‑диаграммы
2. Что такое ER-диаграмма и как ее создать?
3. Проектирование ER-диаграммы
4. Что выбрать для проектирования БД: сравнение UML-диаграммы классов и ER-диаграммы
5. Модель диаграммы Entity Relations (ER) с примером СУБД

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

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

📂 Стратегии работы с кэшем

Ранее описывали процесс кэширования
Рассмотрим подходы к работе с кэшем


Стратегии чтения данных

⏩ Кэширование на стороне (Cache Aside) 

🟡приложение запрашивает данные из кэша
🟡если данные отсутствуют в кэше, приложение запрашивает их из БД
🟡после получения, приложение записывает их в кэш для следующих запросов

Обновление кэша: обновляется только после запроса данных из БД

✅ просто реализовать, контроль за кэшированием на уровне приложения
✖ если данные изменяются в базе, кэш может стать устаревшим

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


⏩ Сквозное чтение (Read Through) 

🟡приложение запрашивает данные только из кэша
🟡если данных нет, кэш сам обращается к БД, извлекает данные и возвращает их приложению, одновременно сохраняя их в кэше

Обновление кэша: автоматически при отсутствии данных в нём, во время запроса из БД

✅облегчает работу приложения, данные автоматически кэшируются при первом запросе
✖ задержка при первом запросе

➡ Новостной сайт, где кэш хранит статьи. Приложение запрашивает статьи из кэша.
Если статьи нет, кэш автоматически получает её из БД, обновляет кэш и передаёт статью пользователю


Стратегии записи данных

⏩ Сквозная запись (Write Around) 

🟡приложение записывает данные напрямую в БД
🟡данные в кэше при этом не обновляются
🟡последующие чтения могут вызвать обновление кэша через механизм Cache Aside

Обновление кэша: приложение запрашивает данные из БД. Получает и записывает их в кэш

✅подходит для данных с редкими операциями чтения
✖кэш может быть неактуальным, при первом запросе данные не кэшируютя сразу

➡ В системе учёта заказов приложение напрямую записывает новые заказы в БД, не обновляя кэш.
Кэш обновляется только при последующем чтении. Изменения редки и не требуют моментальной синхронизации с кэшем


⏩ Сквозная запись (Write Through) 

🟡приложение записывает данные сначала в кэш
🟡кэш автоматически обновляет данные также в БД, синхронизируя их

Обновление кэша: кэш и БД всегда синхронизированы, так как данные записываются одновременно в в БД и в кэш

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

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


⏩ Обратная запись (Write Back) 

🟡приложение записывает данные в кэш
🟡кэш откладывает обновление БД, выполняет его асинхронно через определенные интервалы времени / по необходимости

Обновление кэша: данные в кэше актуальные, но БД обновляется позже, асинхронно

✅быстрая запись данных, поскольку операция записи в БД откладывается
✖риск потери данных в случае сбоя кэша до того, как БД будет обновлена

➡ В соц сети, когда пользователь редактирует профиль, изменения сохраняются в кэш.
Кэш откладывает запись в БД на попозже для асинхрона.
Помогает быстро сохранить изменения пользователя без задержек, хотя БД обновляется с задержкой


Хранение кэша

Кэш в архитектуре приложения обычно хранится в памяти, либо на выделенных серверах для кэширования. Их располагают ближе к приложению для быстрой обработки запросов.
Например,
🟡внутри приложения — локальный кэш
🟡на внешнем сервере / группе серверов — распределённый кэш


📎 Материалы
1. [По полочкам] Кэширование
2. SE: Проектирование эффективной системы кэширования
3. Стратегия кеширования в приложении
4. Все о кэшировании: стратегии, проблемы и оптимизация
5. Все о кэшировании и кэшах
6. Основные принципы кэширования веб-приложений
7. Проектирование эффективной системы кэширования для высоконагруженной системы
8. Cache-aside паттерн
9. Введение в кэширование со сквозным чтением с помощью NCache
10. Продуманные запросы: стратегии кэширования в век PWA

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

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

✍️ Server-Sent Events (SSE)

Server-Sent Events (SSE) —  технология, при которой сервер отправляет клиенту обновления по мере их появления.
Клиенту не нужно отправлять повторяющиеся запросы
Соединение одностороннее: от сервера к клиенту

◾️Для поддержания соединения открытым, сервер может отправлять пустые события с определенной периодичностью, чтобы не закрылось соединение браузером из-за таймаута.

◾️Относится к асинхронным методам, т.к. позволяет получать данные от сервера, как только они становятся доступны, без задержек и постоянных перезапросов.


Как работает

😈клиент делает HTTP-запрос на сервер и  остается подключенным к серверу
😈сервер открывает однонаправленный поток данных, отправляет обновления на клиент в формате текстовых событий
😈онлайн клиент получает данные по мере их поступления с сервера


Где применяется

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


Пример работы SSE для мониторинга системы

💙 Сервер отслеживает метрики системы (загрузка CPU, ошибки, статус сервера)
💙 Клиент подключается через SSE и получает обновления об изменении состояния системы в реальном времени
💙 Как только сервер получает новые данные, он отправляет их клиенту


Плюсы и минусы

➕интегрируется через стандартные HTTP-запросы
➕только сервер инициирует обновления,не нужно постоянно отправлять запросы от клиента на сервер (polling). Это снижает нагрузку
➕автоматически восстанавливает соединение при его потере

➖однонаправленность — только от сервера к клиенту
➖работает только через HTTP, менее гибко по сравнению с WebSocket
➖может не поддерживаться старыми браузерами (работает только с UTF-8)
➖нет возможности передать свои заголовки в запрос


📎 Материалы

1. Асинхронный веб: WebSocket, Server-Sent Events, Long Polling и Short Polling
2. Подписки на GraphQL: Почему мы используем SSE/Fetch вместо Websockets
3. Вам посылка, или Как мы доставляем сообщения с сервера на клиент в реальном времени
4. Server-Sent Events: пример использования
5. Потоковое обновление с событиями, отправленными сервером
6. Server Sent Events
7. WebSockets vs SSE: особенности и сценарии использования

📚Книги
1. Сергей Константинов. API
2. Джей Гивакс. Паттерны проектирования API
3. Арно Лоре. Проектирование веб-API


#api #интеграции

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

✅ SOLID

SOLID — набор принципов проектирования объектно-ориентированных систем.
Помогает создавать гибкую, поддерживаемую и масштабируемую архитектуру.
Нужны для улучшения структуры и качества кода.


SOLID и ООП: в чём разница? 

🔷ООП —  методология или стиль программирования ( с основными свойствами: инкапсуляция, наследование и полиморфизм)
🔴SOLID — набор рекомендаций, как правильно использовать принципы ООП, чтобы создать код, который будет легче поддерживать и расширять
ООП даёт инструменты, а SOLID помогает применять их эффективно.


Принципы SOLID

❤️ — Single Responsibility Principle (Принцип единственной ответственности) 
Каждый класс должен решать одну задачу
делай модули меньше
🟢Пример: класс "Order" отвечает только за управление заказом, а уведомления отправляются другим классом

♥️Связь с ООП: связан с инкапсуляцией — каждый объект скрывает детали своей реализации и выполняет только одну функцию

❤️— Open/Closed Principle (Принцип открытости/закрытости) 
Класс должен быть открыт для расширений, но закрыт для изменений
делай модули расширяемыми

🟢чтобы добавить новый тип отчёта, создаём новый класс, не изменяя существующий код

♥️использует наследование - создание новых классов на основе существующих;
и полиморфизм - способность объектов разных типов использовать общий интерфейс для выполнения различных действий

❤️— Liskov Substitution Principle (Принцип подстановки Барбары Лисков) 
Подклассы должны заменять родительские классы без ошибок
наследуйся правильно
🟢 если класс "Bird" имеет метод "fly", класс "Penguin" не должен его наследовать, так как пингвины не летают

♥️связан с принципом наследования. Подклассы должны правильно реализовывать поведение родительских классов, не нарушать полиморфизм

❤️ — Interface Segregation Principle (Принцип разделения интерфейса) 
Узкие специализированные интерфейсы лучше, чем один общий
дроби интерфейсы
🟢вместо общего интерфейса "Animal" создаём отдельные интерфейсы "Flyable", "Swimmable", "Runnable"

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

❤️ — Dependency Inversion Principle (Принцип инверсии зависимостей) 
Модули должны зависеть от абстракций, а не от конкретных реализаций
используй интерфейсы
🟢класс "UserService" зависит от интерфейса "Database", а не от конкретной реализации БД

♥️использовании абстракций (отделения концепции от её реализации);
и полиморфизма для уменьшения зависимости между модулями


❗Нарушение SOLID приводит к антипаттернам, таким как "God Object" (класс с множеством задач) или "Spaghetti Code" (запутанный код)


Зачем аналитику SOLID? 

➡️ поможет оценить архитектуру на этапе проектирования
🟢например, при добавлении новых способов оплаты система не должна требовать переписывания основного кода (принцип ❤️)

➡️ для составления требований к разработке и задач рефакторинга
🟢 если каждая функция изолирована, то изменения не затронут другие модули (принцип ❤️)

➡️ для согласования архитектурны с разработкой
🟢 корректное использование интерфейсов предотвратит сложную интеграцию с новыми системами в будущем (принцип ❤️)


📎 Материалы
1. Принципы SOLID в программировании — что это такое
2. SOLID
3. Простое объяснение принципов SOLID
4. SOLID принципы: что это такое и зачем они нужны?
5. SOLID — это несложно. С примерами на Python
6. SOLID == ООП?

📚Книги
1. Чистая архитектура — Роберт Мартин
2. Объектно-ориентированный анализ и проектирование с примерами приложений - Грэди Буч
3. Объектно-ориентированное мышление - Мэтт Вайсфельд
4. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Хелм Ричард, Влиссидес Джон

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

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

✍️ ESB / MOM / MQ

🟣ESB (Enterprise Service Bus, шина данных) — посредник для обмена данными между системами. Объединяет системы и приложения в единую интеграционную архитектуру. Управляет бизнес-логикой и маршрутизацией данных

🟡MOM (Message-Oriented Middleware) — промежуточное ПО для асинхронной передачи сообщений между приложениями

🟣MQ (Message Queue) — реализация системы очередей, частный случай MOM

MOM/MQ — не шины данных, но могут быть частью решения, основанного на шине


ESB (Enterprise Service Bus)

🟣управление данными идет через одну точку позволяет контролировать потоки данных
🟣применяется для большого количество приложений с разными протоколами и форматами данных
🟣обеспечивает маршрутизацию, трансформацию и оркестрацию сообщений между ними
🟣часто используется с легаси-системами для интеграции старых приложений с новыми
🟣может направлять сообщения между системами через MOM или MQ

Как работает

1. приложение отправляет данные на ESB через адаптер (например, для БД или веб-сервиса)
2. ESB преобразует формат данных, если требуется
3. шина маршрутизирует сообщение в нужное приложение
4. получатель получает сообщение и обрабатывает его


Шина данных считается устаревшим видом интеграции:

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

Пример: Apache Camel, MuleSoft


MOM (Message-Oriented Middleware)

🟣может поддерживать очереди (MQ), публикацию/подписку (Pub/Sub), маршрутизацию, обработку событий
🟣используется, когда не нужно дожидаться ответа от другой системы
🟣полезен в микросервисной архитектуре, чтобы разгрузить приложение и повысить отказоустойчивость

Как работает

1. приложение отправляет сообщение посреднику (MOM)
2. посредник сохраняет сообщение в буфере до тех пор, пока приложение-получатель не будет готово его принять
3. получатель обрабатывает сообщение, когда готов
4. MOM удаляет сообщение из буфера только после его успешной доставки

Пример: ActiveMQ, RabbitMQ - поддерживают и очереди, и другие модели, такие как Pub/Sub


MQ (Message Queue)

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

Пример: IBM MQ


📎 Материалы
1. От хаоса к порядку: как легко интегрировать сервисы с помощью Enterprise Service Bus
2. Шины данных (ESB): зачем компаниям использовать этот инструмент
3. Почему технари против шин данных: middleware, ESB, брокеров сообщений?
4. Как я 10 лет строю интеграцию в банке: от ESB-монолита к целой линейке систем
5. Уже поменяли шину? Наш опыт «переобувания» и разработки интеграционной платформы
6. ESB интеграция: объяснение и цель
7. Что такое MQ? Основные понятия
8. Интеграция на основе сообщений. Преимущества и отличия от других подходов
9. Кафка это шина? API, MQ, шины/ESB. Неочевидные минусы подходов и их плюсы

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

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

🔹 БАЗА ЗНАНИЙ ПО СИСТЕМНОМУ АНАЛИЗУ 🚀

Все посты из канала за всё время разложены по полочкам в едином месте — базе знаний 🤓

Наша цель — сделать кладезь знаний системного аналитика 🧠

Какие плюшки вас ждут:

🗂 Все знания в едином месте: кратко, ёмко, без воды и с подборками полезных материалов 🔥

🔎 Удобный поиск и навигация: все наши конспекты структурированы по группам навыков СА и есть поиск по тексту — вы не утоните в тоннах воды и часах гуглинга

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

📝 Контент на заказ бесплатно: хотите материал на конкретную тему? Любой покупатель может оставить запрос, и мы сделаем обзор с исчерпывающей подборкой материалов абсолютно бесплатно!

➡️ Приобрести вечный доступ к постоянно обновляемой Базе знаний по цене айтишниой книги можно тут — всего 4900 ₽

На analitik.me можно узнать про Базу знаний больше.

P.S. Если нет карты РФ и по любым другим вопросам можно писать сюда: @radale

🙂 Архитектурные паттерны (MV(X)

Архитектурные паттерны — шаблоны для высокоуровневой организации системы.
Определяют основные компоненты системы, их взаимосвязи и взаимодействия

Паттерны MV(X) используются в
🟡мобильных и веб приложениях
🟡банкинге и финансовых системах, где важны четкая структура и гибкость
🟡в играх и графических интерфейсах (для отделения логики от UI и управления сложными связями)

MV(X) — семейство паттернов со схожей структурой
Разделяют приложения на основные компоненты:
⏩ Model — отвечает за данные, бизнес-логику, сервисы для работы с БД и сетью (например, класс в ООП, API, библиотека, микросервис и тд)
⏩ View — визуальное представление для пользователя, отображение данных из Model
❕эти компоненты выполняют одни и те же роли во всех паттернах MV(X)
⏩ Presenter / Controller / ViewModel - меняются в зависимости от паттерна

✅ Чем лучше разделение обязанностей между компонентами,
тем проще управлять проектом, добавлять и тестировать компоненты

Рассмотрим некоторые из них:

MVC (Model-View-Controller)

Controller: логика, которая связывает model и view
➡ направляет данные от пользователя к системе и наоборот
➡ напрямую обновляет view

Подходит для небольших / средних приложений
Чем проще Controller, тем лучше

Пример

В веб-приложении для управления библиотекой:
🟡Model: класс Book с полями noscript, author и методами для работы с книгами
🟡View: HTML-страница с формой для добавления книг и списком всех книг
🟡Controller: обработчик, который принимает POST-запросы на добавление книг и обновляет Model и View

Недостатки

✖ в больших приложениях Controller объемный ➡ сложнее поддержка кода
✖ View и Model разделены, но View и Controller тесно связаны ➡ тяжелее масштабировать каждый из этих компонентов
✖View и Controller тестировать сложно из-за тесной связи ➡ тестируется в основном Model


MVP (Model-View-Presenter)

Presenter: полностью управляет логикой view
➡ обрабатывает ввод
➡ взаимодействует с моделью
➡ обновляет view через интерфейс, не зависит от конкретной реализации view (как у controller)

Отличие от MVC: связь view и model идет через presenter, а не напрямую

Эффективен в приложениях с высокой нагрузкой на UI,
и где необходимы модульные тесты, т.к. Presenter можно тестировать

Пример

В Android-приложении для управления задачами:
🟡Model: класс task, представляет задачу с полями noscript, denoscription и методами для изменения состояния
🟡View: UI для отображения списка задач и формы для добавления новой задачи
🟡Presenter: объект, который запрашивает список задач из Model и обновляет View при изменениях

Недостатки
✖ требует создания доп классов и интерфейсов ➡ может перегружать простые приложения


MVVM (Model-View-ViewModel)

View взаимодействует с ViewModel через привязку данных

ViewModel
🟡содержит свойства и команды, к которым привязывается View
🟡взаимодействует с Model для извлечения или обновления данных

Эффективен для приложений со сложными структурой данных и интерфейсом

Пример

В WPF-приложении для управления контактами:
⭕Model: класс Contact содержит информацию о контакте
⭕View: UI, показывает список контактов и формы для добавления/редактирования
⭕ViewModel: объект, который загружает данные из Model и обновляет View, а также обрабатывает команды от View

Недостатки
✖ сложно настроить привязку данных
✖ ViewModel может перегружаться лишней логикой


📎 Материалы
1. MVC
2. Достоинства использования MVC архитектуры в разработке клиент-серверного интернет-магазина
3. Что такое MVP архитектура
4. Реализация MVC паттерна на примере создания сайта-визитки на PHP
4. MVC против MVVM — разница между ними
5. Понимание различий: MVC и MVVM
6. Шпаргалка по MV-паттернам для проектирования веб-приложений
7. Архитектурные шаблоны: объяснение MVC, MVP и MVVM
8. Паттерны для новичков: MVC vs MVP vs MVVM


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

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

✍️ Транзакции в Apache Kafka

Kafka поддерживает транзакции, чтобы гарантировать выполнение операций по принципу «всё или ничего»
Такая гарантия доставки называется exactly-once

Подробнее о других типах гарантии доставки тут

Когда применяется

🔘если требуется согласованность между несколькими топиками
🔘в операциях, где частичное изменение данных недопустимо (в финансовых приложениях, логистике, управлении запасами и заказами


Как работают транзакции в Kafka

⭕продюсер начинает транзакцию, присваивает  уникальный transactional.id. Это идентификатор, который отличает записи транзакций
⭕продюсер отправляет сообщения в одну / несколько очередей с пометкой "транзакционные"
⭕продюсер подтверждает данные (коммит) или отменяет (откат)
Коммит фиксирует сообщения, и они становятся видимы потребителям, в противном случае --  откатываются


ACID в Kafka

◾️атомарность (Atomicity): вся группа сообщений фиксируется сразу
◾️согласованность (Consistency): контроль за статусами сообщений в метаданных
◾️изолированность (Isolation): с помощью настройки read_committed (на стороне консьюмера) потребители могут видеть только зафиксированные данные, пока транзакция не завершена
◾️долговечность (Durability): достигается за счёт репликации и журналов с зафиксированными сообщениями


Плюсы и минусы

💚гарантия целостности операций с использованием ACID
💚защита от дублирования и конфликтов через изоляцию транзакций

💚требуют больше ресурсов, что может снизить производительность
💚поддерживаются с 0.11.0 версии Kafka


Пример транзакции в Kafka

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

Есть два топика в Kafka:
— orders: хранит общую информацию о заказе
— inventory: содержит информацию об изменении запасов после заказа

Шаги для транзакции:
🟡создать продюсера с transactional.id 
🟡отправить сообщения в транзакции: записать детали нового заказа в оба топика orders и inventory
⏩ если успешно, фиксируется (коммит) транзакция: сообщения видны для потребителей обоих топиков
⏩ если ошибка, транзакция откатывается: ни одно сообщение не попадёт в топики

Результат: транзакция гарантирует, что потребители прочтут согласованные данные


📎 Материалы
1. Изоляция транзакций в Apache Kafka при потреблении сообщений
2. Семантика exactly-once в Apache Kafka
3. Транзакции в Apache Kafka: атомарность публикации сообщений
4. Что такое гарантия доставки сообщений или как избавиться от дублей и потерь в Apache Kafka и других Big Data брокерах

📚 Книги
1. Kafka в действии -- Дилан Скотт, Виктор Гамов и Дейв Клейн
2. Apache Kafka. Потоковая обработка и анализ данных -- Гвен Шапира, Тодд Палино, Раджини Сиварам, Крит Петти
3. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples in Java -- Emil Koutanov (англ)

#интеграции

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу