⌛ SDLC: Жизненный цикл ПО

Жизненный цикл программного обеспечения (Software Development Life Cycle, SDLC) — структурированный процесс создания систем
Путь идеи от концепции до рабочего продукта


Фазы жизненного цикла ПО

1️⃣Инициация (Планирование)

Определяется цель проекта, его границы и заинтересованные стороны
Оценивается бизнес-ценность, риски и целесообразность разработки
Результат фазы — бизнес-кейс, дорожная карта проекта, первичные требования и оценка ресурсов

2️⃣ Сбор и анализ требований

Вывляются:
🔸проблемы бизнеса, которые нужно решить
🔸функциональные требования (что система должна делать)
🔸нефункциональные требования (какими качествами обладать: производительность, безопасность, надежность)

Выходные артефакты: ТЗ или спецификация требований к ПО (SRS), модели процессов, диаграммы прецедентов

3️⃣ Проектирование

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

〰️архитектура системы: Выбираются технологии, определяются основные компоненты и их взаимодействие (микросервисы, монолит)
〰️проектирование данных: разрабатывается модель БД
〰️проектирование интерфейсов: как система будет взаимодействовать с пользователями (UI) и другими системами (API)

Результат — набор архитектурных и дизайнерских документов

4️⃣ Разработка (реализация)

Пишется код в соответствии с архитектурой и требованиями
Ревью кода, сборка и автоматизация сборочного процесса через CI/CD

На выходе — рабочие модули и инкременты системы

5️⃣ Тестирование

Проверяется соответствие продукта требованиям

Примеры тестирования:
⚫️модульное (проверка отдельных компонентов)
⚫️интеграционное (проверка взаимодействия компонентов)
⚫️системное (проверка системы в сборе по всем требованиям)
⚫️приемочное (финальная проверка с заказчиком)

6️⃣ Внедрение

Продукт разворачивается в целевой среде

〰️развертывание на production-серверах
〰️перенос данных из старых систем
〰️обучение пользователей
〰️подготовка документации

Завершается релизом и переходом системы в эксплуатацию

7️⃣ Эксплуатация и сопровождение

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

Фаза продолжается до момента окончательного вывода системы из эксплуатации


Модели жизненного цикла ПО

Подход к организации фаз SDLC определяется моделью: как эти фазы взаимодействуют друг с другом, их последовательность

🔵 Последовательные (плановые)

🔹Каскадная (Waterfall)

Фазы выполняются строго последовательно: от анализа до сопровождения
Переход на следующую стадию возможен только после завершения предыдущей

Подходит для проектов с чётко определёнными и стабильными требованиями

🔹 V-модель (Verification & Validation)

Идея каскада с добавлением акцент на тестирование
Каждая стадия разработки имеет свой этап проверки и валидации

🟢 Инкрементальные

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

В результате пользователь постепенно получает готовые части системы

🟡 Итерационные (адаптивные)

🔸Спиральная

Комбинирует идеи каскадной и прототипной моделей
Каждая итерация проходит все фазы SDLC, но с акцентом на анализ рисков

Применяется для крупных и исследовательских проектов

🔴 Гибкие (Agile)

🔸 Scrum

Разработка короткими итерациями — спринтами (1–4 недели). Команда поставляет работающий инкремент продукта к концу каждого спринта.

🔸 Kanban

Ориентирован на непрерывный поток задач и визуализацию процессов
Основной инструмент — канбан-доска, где задачи перемещаются по статусам


📎 Материалы
1. Этапы жизненного цикла разработки ПО или что такое SDLC?
2. SDLC
3. База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия
4. Про семь основных методологий разработки
5. Модели жизненного цикла ПО

📚 Книги
Управление проектным бизнесом от Алексея Васильева

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

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

📌 Event Storming

Event Storming — техника коллективного моделирования бизнес-процессов

Строится вокруг событий (domain events), которые отражают значимые изменения состояния системы (заказ создан», платёж подтверждён, товар доставлен)

Помогает
🔵выявить ключевые процессы, связи и точки интеграции
🔵создать основу для проектирования архитектуры
🔵увидеть все "узкие места", противоречия и пробелы бизнес-процесса


Примеры приименения

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

Основные принципы

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


Типы Event Storming-сессий

✳️ Big Picture
Используется для получения общего представления о домене
Позволяет увидеть ключевые процессы и зависимости между ними

➡️ пример: визуализация полной цепочки "Заказ → оплата → доставка → возврат"

✳️ Process Level
Детализирует конкретный бизнес-процесс
Помогает определить события, команды и участников внутри него

➡️ разбор процесса "возврат товара" — от запроса покупателя до перевода средств

✳️ Design Level
Уточняет модель до уровня архитектуры и bounded contexts
Используется при проектировании микросервисов и взаимодействий между ними

➡️ разбиение домена e-commerce на контексты — заказы, платежи, доставка, уведомления


Ключевые «строительные блоки»

🔵 Domain Event (событие предметной области): главный элемент
Факт, который уже произошел в системе.
➡️ заказ размещён, платёж подтверждён, товар отправлен клиенту

🔵 Command (команда): действие, которое инициирует выполнение операции и приводит к событию
Часто является реакцией на предыдущее событие
➡️ разместить заказ, подтвердить платёж, отправить товар

🔵 Actor (Актор): пользователь или внешняя система, которая вызывает команду
➡️ покупатель, платёжный шлюз

🔵 Aggregate (агрегат): понятие из DDD
Это "кластер" из связанных сущностей (например, заказ с его позициями), который обрабатывает команды и порождает события

🔵 Policy (политика / бизнес-правило): автоматическая реакция на событие
Формулируется как "Когда событие X, тогда команда Y"

➡️ когда "Платёж подтверждён", тогда "Отправить товар"

🔵 Read Model (модель чтения): данные, которые видит пользователь, чтобы принять решение и выполнить команду
➡️ Страница со списком товаров в корзине


Пример как проходит Event Storming

1. Определить границы процесса
➡️ от момента оформления заказа до его доставки

2. Зафиксировать доменные события в прошедшем времени
➡️ заказ создан, платёж подтверждён, уведомление отправлено

3. Добавить команды, которые инициируют события:
➡️ создать заказ, подтвердить платёж

4. Указать акторов
➡️ кто выполняет действие (пользователь, внешний сервис)

5. Добавить агрегаты и сущности
➡️ они изменяют состояние при выполнении команд

6. Зафиксировать политики и правила
➡️ после подтверждения платежа — отправить заказ

7. Сгруппировать события по смыслу
➡️ формируются bounded contexts — логические границы между частями системы

8. Проверяются связи, исключения, альтернативные сценарии

9. Результат: карта событий, отражающая процессы и зависимости


📎 Материалы
1. Event storming
2. Моделирование микросервисов с помощью Event storming
3. Event Storming: как построить модель вокруг событий
4. Введение в Event Modeling
5. 10 аналогов Miro от российских и иностранных разработчиков

📚 Книги
Предметно-ориентированное проектирование: паттерны, принципы и методы - Скотт Миллетт, Ник Тью

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

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

Грокаем безопасность веб-приложений

✍️ Автор: Макдональд Малькольм
🗓 Год издания: 2025
🔤 Язык: русский
📚 Объём: 336 стр.


Практическое руководство по безопасности для веб-приложений.
◾️Раскрываются основные принципы защиты
◾️Подробно разбираются наиболее распространенные уязвимости веб-приложений — от браузера до сервера.

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

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


#безопасность

✔️ Советы по проектированию REST API


1. Использовать множественное число для коллекций
✅ GET /products
✅ GET /products/{product_id}
❌ GET /product/{product_id}


2. Не добавлять лишние сегменты в путь
✅ GET /v3/application/listings/{listing_id}
❌ PATCH /v3/application/shops/{shop_id}/listings/{listing_id}

Не пытаться отразить всю модель данных в URL
Если listing_id уникален — shop_id не нужен

💙 Исключение: если ключ действительно составной

GET /listings/{listing_id}/options/{option_id}

3. Не добавлять расширения в URL

❌ GET /users.json

Формат передачи должен определяться через HTTP-заголовки (например, Accept) , не через URL
✅ GET /users и HTTP-заголовки настройка заголовков:

Accept: application/json

4. Не возвращать массивы верхнего уровня

Объект позволяет легко добавить пагинацию и дополнительные поля без поломки обратной совместимости

❌ [{"id":1}, {"id":2}]
✅ { "data": [{"id":1}, {"id":2}] }


5. Не возвращать структуры-словари (map)

Словари ломают совместимость и неудобны для типизированных языков.
💙 Исключение: простые пары ключ: значение (например, metadata)

✅ { "data": [{ "id":"KEY1" }, { "id":"KEY2" }] }
❌ { "KEY1": {...}, "KEY2": {...} }


6. Добавлять префиксы к ID

✅ Помогает отличать типы сущностей и уменьшает путаницу при поддержке
Примеры:

Stripe: in_1MVpWEJVZPfyS2HyRgVDkwiZ
Shopify: gid://shopify/FulfillmentOrder/1469358604360

7. Не использовать 404 для “не найдено”

❌ 404 Not Found может означать сетевую ошибку или неверный URL
🔹может быть возвращен прокси, балансировщиком нагрузки и т.д.
🔹не позволяет клиенту отличить "ресурс не существует" от "ошибка конфигурации"

✅ Использовать, например, 410 Gone — сервер понял запрос, но объекта нет


8. Ошибки в структурированном формате

✅Позволяет передавать цепочку ошибок и упрощает отладку

{
  "message": "Access denied",
  "type": "Unauthorized",
  "types": ["Unauthorized", "Security"],
  "cause": { ... }
}

9. Идемпотентность операций

Идемпотентность = повтор вызова не меняет результат

🔹 GET, PUT, DELETE — по определению идемпотентны
🔹 Для POST добавлять идемпотентный ключ: клиент отправляет уникальный ключ в заголовке или теле, а сервер проверяет его уникальность

POST /orders
Idempotency-Key: abc123

Если запрос повторится — сервер вернёт 409 CONFLICT и ID уже созданного ресурса:

{
    "message": "Duplicate",
    "old_id": "ORD123"
}

Клиент уверен, что заказ не задублировался


10. ISO8601 для даты и времени

А также использовать ISO8601 для интервалов и длительностей
✅ "2023-12-21T11:17:12.34Z"
❌ "1703157432340"

🔹ISO8601 человеко-читаем
🔹поддерживается всеми библиотеками
🔹работает в UTC


#api

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

Изучаем DDD — предметно-ориентированное проектирование

✍️ Автор: Влад Хононов
🗓 Год издания: 2024
🔤 Язык: русский
📚 Объём: 320 стр.

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

Рассказано
🔹как оценить масштаб и сложность предметной области (с примерами анализа предметной обалсти)
🔹измерить темпы ее развития, учесть необходимые зависимост
🔹про архитектурные паттерны и паттерны взаимодействия, EventStorming, SOA, Data Mesh
🔹применять DDD и структурировать создаваемое ПО эффективно вписывая его в сеть данных (Data Mesh)
🔹о порядке развития проекта синхронно с изменениями в его бизнес-контексте

Знание принципов и шаблонов предметно-ориентированного проектирования будет полезно инженерам-программистам всех уровней: младшего, старшего, штатного и руководящего.


🔹 Пост про DDD

📺 Интервью с автором Learning Domain-Driven Design • Влад Хононов

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

🔼 Workflow-движок

Workflow-движок — система, которая управляет выполнением последовательности шагов (задач) по описанной логике процесса:
🔹 какие действия выполняются, в каком порядке, кто за них отвечает и какие условия переходов между шагами

Нужен, когда в системе есть повторяющиеся, формализованные процессы:
состоящие из нескольких этапов
с предсказуемыми переходами и условиями
▶️Реализует паттерн оркестрации


Как работает

Компоненты:
*️⃣ модель процесса: описание шагов, условий, участников и маршрутов
форматы: BPMN, JSON, YAML, собственные DSL
*️⃣ движок исполнения: интерпретирует модель, управляет выполнением шагов
*️⃣ хранилище состояния процессов (активные задачи, контекст данных)
*️⃣ интерфейс взаимодействия: API или UI для запуска, мониторинга и управления процессами
*️⃣ исполнители (workers): внешние сервисы / люди, выполняющие задачи

Принцип:
🔸описывается процесс
🔸движок интерпретирует модель, создаёт экземпляр процесса
🔸каждый шаг выполняется человеком / системой
🔸движок отслеживает статус и двигает процесс дальше по маршруту

Типовой цикл:
1. запуск — процесс стартует по событию или API-запросу
2. исполнение — движок выполняет шаги, проверяет условия переходов
3. ожидание — если требуется ввод данных пользователем или внешним сервисом
4. завершение — финальный статус, логирование результатов


Примеры

➡️ согласование документов (HR, закупки, договоры)
➡️ автоматизация CI/CD (деплой по цепочке шагов)
➡️ маршрутизация заказов между системами
➡️ оркестрация микросервисов — последовательный вызов нескольких API

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

🔹 клиент / внешняя система инициирует процесс через API
🔹 workflow-движок получает запрос, создаёт экземпляр процесса
🔹 для каждого шага движок вызывает нужный сервис (REST, gRPC, очередь сообщений)
🔹 после завершения шага обновляет состояние и двигается к следующему
🔹 все статусы сохраняются в базе состояний, откуда можно извлечь историю / отчётность


Когда использовать

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

Не стоит использовать:
➖ процесс слишком простой (один-два шага)
➖ бизнес-логика часто меняется и неформализуема


Workflow vs. BPM

🟢 Workflow-движок исполняет процессы
🟡 BPM-платформа управляет ими в широком смысле — моделирует, оптимизирует, анализирует

📌Часто BPM-платформы включают внутри себя workflow-движок как исполнительный слой


Примеры ПО

➖ Temporal
➖ n8n
➖ Camunda
➖ OpenBPM Engine


📎 Материалы

1. Workflow Core — движок бизнес-процессов для .Net Core
2. Как мы делали свой движок Workflow
3. Интеграция с «Госуслугами». Применение Workflow Core (часть II)
4. Интеграционная платформа в The Platform: что умеет, как работает и зачем ей Workflow Engine

#интеграции

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

⬇️ JSON Patch

JSON Patch — формат для описания изменений в JSON-документе
Вместо отправки документа для обновления, отправляется набор операций («патч»), которые нужно применить

⚫️экономит трафик, делает изменения предсказуемыми и атомарными
⚫️описан в стандарте RFC 6902


Примеры применения

🤩в RESTful API для частичного обновления ресурсов (PATCH-запросы)
🤩для синхронизации состояния между клиентами
🤩где важно версионирование
🤩в event-sourcing как событие


Пример

Исходно:

{ "user": "Иван", "age": 30 }

Патч (набор операций):

[
  { "op": "replace", "path": "/age", "value": 31 },
  { "op": "add", "path": "/city", "value": "Москва" }
]

Результат:

{ "user": "Иван", "age": 31, "city": "Москва" }

Особенности

➡️Строгий формат операций
RFC 6902 определяет только 6 операций:
- add
- remove
- replace
- move
- copy
- test

Расширять этот набор другими операциями нельзя, если нужно сохранить совместимость с системами, реализующими  RFC 6902


➡️Применяется атомарно
Если любая операция в массиве завершается ошибкой (например, путь не найден для remove, или операция test возвращает false), весь патч должен быть откачен, и документ остается без изменений
Это гарантирует целостность

➡️Операции применяются последовательно
Последующие могут зависеть от результата предыдущих
⚫️Пример: чтобы переместить (move) данные из /a в /b, сначала убедиться, что /b не существует, или удалить его в предыдущей операции


JSON Patch vs JSON Merge Patch

✨JSON Merge Patch (RFC 7396) - простой формат для слияния JSON-документов
Отправляется фрагмент, который нужно "наложить" на целевой документ:
- значения заменяются
- null означает "удалить поле"
- отправляются только изменяемые поля

Когда использовать

🤩Merge Patch — для простых обновлений объектов (конфиги, настройки пользователя)
🤩JSON Patch — когда нужна точность: работа с массивами, контроль целостности, синхронизация


📎 Материалы
1. Оптимизация трафика при синхронизации состояний через Jsonpatch
2. Убегайте от праздника «пустых» проверок: правильно выполняйте PATCH с помощью JSON Patch

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

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

🧠 Brainstorm

Брейншторм (мозговой штурм) — групповой метод генерации идей для решения задачи или поиска вариантов
Это не обсуждение и не поиск лучшего решения
💙А способ найти варианты решений

🎯 Цель: получить максимально широкий набор идей за ограниченное время без их оценки на этапе генерации

Проводится в два этапа:
💙 сначала — генерация идей
💙затем — анализ, отбор и принятие решений


Роли участников

✨фасилитатор — управляет процессом, следит за правилами, не предлагает решения
✨участники — генерируют идеи, не критикуют, не оценивают
✨наблюдатель (опционально) — подключается на этапе анализа


Зачем нужен

◾️задача открытая, без заранее известного решения
◾️есть риск застрять в очевидных или привычных решениях
◾️требуется быстро собрать идеи от разных ролей и точек зрения
◾️проекты на начальных, неопределенных стадиях

Когда не нужен

➖ у задачи однозначное решение (например, по регламенту или стандарту)
➖ требуется точный расчет или экспертиза одного специалиста
➖ решение уже принято, нужна его реализация


Пример

💙 Поиск корневой причины сбоя в процессе

💙Ситуация: в еженедельном отчете падает количество успешных транзакций.
💙Задача для брейншторма: что привело к снижению числа успешных платежей?
💙Результат - сгенерированные гипотезы:
- обновление страницы оплаты
- проблемы у платежного провайдера
- изменения в анти-фрод системе
- ошибка в кешировании данных
- сезонный фактор
Cоздается список направлений для дальнейшей проверки


Базовые правила

1. Запрещена критика идей
2. Количество важнее качества. Цель — заполнить доску вариантами
3. Поощряются нестандартные идеи
4. Идеи можно развивать и комбинировать


Техники

💙 Классический брейншторм

Когда использовать: простые открытые задачи
Как проводится: участники устно предлагают идеи, фасилитатор фиксирует

➕ простота, высокая скорость
➖ риск доминирования активных участников

Пример: генерация вариантов пользовательских сценариев

💙 SCAMPER

Когда: улучшение текущего решения
Как: генерация идей по наводящим вопросам
💙(Substitute (Заменить)
💙Combine (Комбинировать)
💙Adapt (Адаптировать)
💙Modify/Magnify Модифицировать/Увеличить)
💙Put to other uses (Применить иначе)
💙Eliminate (Устранить)
💙Reverse/Rearrange (Перевернуть/Изменить порядок)

➕ структурированный подход
➖ не подходит для задач «с чистого листа»

Пример: Оптимизация бизнес-процессов

💙 Six Thinking Hats

Когда: cложные задачи, конфликт мнений
Как: участники мыслят в заданных ролях
➕ снижает споры, структурирует обсуждение
➖ требует подготовки
Пример: проработка архитектурных альтернатив

💙 Обратный брейншторм

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


📎 Материалы
1. Топ 8 инструментов для мозгового штурма
2. 15 способов превратить мозговой штурм в результат «огонь»
3. Пять техник мозгового штурма
4. Что такое мозговой штурм и как правильно его проводить в компании
5. Как провести мозговой штурм: основные правила, методы и ошибки

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

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

❌ Баги аналитики

Код написан, всё успешно протестировано, фича на проде, а бизнес в шоке... Знакомо?
💙Это то, что мы с вами не учли на этапе написания ТЗ

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

Баги от нас стоят дороже всего
💙Но их предотвращение — экономит деньги компании больше всего


Антипаттерны аналитики

1️⃣ Не все требования фиксируются письменно

Существуют на словах, "очевидно же"
В итоге на прод попадает функционал, где клиент-иностранец может получить налоговый вычет
💙 Все требования фиксируем в артефакте

2️⃣ Не все требования согласовываются с бизнесом

После релиза менеджер залетает с ноги и возмущается, почему не учли то-то.
А это нигде не зафиксировано
💙 Обязательно получаем ОК от заказчика по требованиям перед тем, как писать детальное ТЗ

3️⃣ Лоскутное описание процессов

Не продуман процесс целиком, нет e2e описания, как должно работать
В итоге ни у кого нет понимания общей картины. Даже у аналитика
💙 Составлять верхнеуровневое описание процесса до написания ТЗ

4️⃣ Не обращать внимания на вариации и корнер-кейсы

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

5️⃣ Неверный уровень детализации ТЗ

💙 Слишком подробные, кодоподобные ТЗ затрудняют чтение и требуют реверс-инжиринга
Никто, кроме аналитика, ничего не поймёт
💙 Слишком поверхностные ТЗ упускают детали → ловим баги на проде
💙 Иметь шаблоны ТЗ под каждый тип задачи

6️⃣ Доверять документации

Вообще, слово "доверять" не про аналитиков :)

Руководствуемся критическим мышлением, слепо доверять мы не можем
Например, при описании интеграции с внешним сервисом нельзя взять и скопипастить в своё ТЗ пример запроса и ответа. Нужно проверять вручную
💙 Критически относится к чужой документации. Всегда проверять всё, что можно проверить

7️⃣ Не закладывать идемпотентность и дедубликацию
В той самой статье про Васю всё сказано, добавить нечего

➿➿➿➿➿➿➿➿
⬇️ Продолжение следует ... за Вами!

Давайте добавим краудсорсинга в комментариях к этому посту — обменяемся своими факапами (админ первый).
Соберём всё и выложим продолжение

P.S. Если формат зайдёт, будем практивать и дальше.
Примерно так:
мы даём начало 💙 обмен опытом в комментах 💙 собираем в финальный пост.
Ну и как всегда — выложим в базу знаний по системному анализу

🔼 Слоистая архитектура

Слоистая архитектура — подход, при котором система разделяется на логические слои

💚Каждый отвечает за строго определённую группу задач и взаимодействует с другими слоями по правилам


Базовые принципы

💚 Разделение ответственности

Каждый слой решает 1 категорию задач:
💚взаимодействие с пользователем/внешними клиентами
💚управление бизнес-процессами
💚бизнес-правила
💚работа с данными и внешними системами

Слой не должен брать на себя задачи вне его зоны ответственности

💚 Однонаправленные зависимости

Зависимости направлены сверху вниз:
💚верхние слои используют нижние
💚нижние не знают о верхних

Снижает связанность и упрощает изменение системы

💚 Контракты между слоями

Контракт слоя — формальное описание:
💚какие данные слой принимает
💚какие данные возвращает
💚какие ошибки и ограничения возможны

⭕контракт важнее реализации
⭕верхний слой знает контракт, но не реализацию
⭕реализацию можно заменить (другая БД, другой внешний сервис), не меняя вызывающий слой

💚 Изоляция изменений

Изменения в одном слое не должны затрагивать другие, если контракт сохранён

Пример:
📍смена БД не требует изменений в бизнес-логике
📍смена UI не влияет на доменные правила


Типовая структура

⏩ Презентационный слой (Presentation Layer)

🟡принять запрос
🟡проверить формат данных
🟡вернуть результат пользователю или клиенту

Включает:
⭕UI (веб, мобильный, desktop)
⭕REST / GraphQL контроллеры
⭕валидацию формата данных

Не должно быть:
✖ бизнес-логики,
✖ прямой работы с БД

⏩ Слой приложения (Application / Service Layer)

🟡управлять сценариями использования (use cases)
🟡определять последовательность шагов
🟡управлять транзакциями и безопасностью

Включает:
⭕сервисы приложений
⭕оркестрация логики
⭕обработку ошибок сценариев

Отвечает на вопрос «что именно нужно сделать», но не содержит бизнес-правил


⏩ Бизнес слой (Domain / Business Layer)

🟡реализация бизнес-правил и ограничений
🟡хранение данных предметной области

Включает:
⭕сущности
⭕доменные сервисы
⭕бизнес-инварианты

Ключевой слой, ради которого существует система

Не должно быть:
✖ логики UI
✖ SQL, HTTP-вызовов
✖ технических деталей хранения данных


⏩ Инфраструктурный слой (Infrastructure Layer)

🟡реализация технических деталей
🟡работа с БД
🟡интеграции с внешними системами
🟡файловые хранилища, очереди, API, кэш

Включает:
⭕репозитории
⭕ORM
⭕HTTP-клиенты


Типовой поток запроса

1. Presentation Layer принимает запрос
2. Application Layer запускает сценарий
3. Domain Layer выполняет бизнес-логику
4. Infrastructure Layer читает или сохраняет данные
5. Результат возвращается вверх


Другие слои

🟡Integration — изоляция внешних API и интеграций
🟡Security — авторизация, аутентификация, ACL
🟡Caching — работа с кэшем (Redis и аналоги)
🟡Messaging / Event — очереди, события, асинхронное взаимодействие

Это не обязательные слои
Их выделяют, если появляется отдельная ответственность
Лишние слои усложняют систему


Когда использовать

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

✖ система одноразовая
✖ минимальная логика
✖ критична каждая миллисекунда задержки


📎 Материалы
1. Слоистая архитектура приложений: как обеспечить поддерживаемость доменного слоя
2. Трехслойная и трехзвенная: введение в архитектуру ИС для аналитика
3. Слоистая архитектура
4. Архитектура приложения: что это, какие есть виды и как проектировать

📚 Книги
1. Архитектура ПО. Руководство для обучающихся архитектурному мышлению - Ганди Раджу, Ричардс Марк, Форд Нил
2. Идеальная архитектура. Ведущие специалисты о красоте программных архитектур - Диомидис Спинеллис, Георгиос Гусиос
3. Архитектура программного обеспечения на практике - Л. Басс, П. Клементс, Р. Кацман
4. Александр Швец. Погружение в Паттерны Проектирования

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

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

🔵🗣Вырасти до хардового Middle+ аналитика.
Как? Добавьте к своим скилам навыки в проектировании архитектуры и интеграций веб-сервисов!

Рассмотрите — авторский курс про архитектуру и интеграции
с практикой.
—————
По результатам курса вы:
▫️научитесь выбирать стиль интеграции под вашу задачу;
▫️сможете проектировать с нуля и описывать интеграции в современных стилях (API: REST, SOAP, gRPC и др. + брокеры сообщений);
▫️поймете, как правильно собирать требования и моделировать в UML;
▫️подготовитесь к собеседованию, решив более 100 тестов;
▫️разработаете свой API на Python;
—————
🟢Вы получите большую базу фундаментальных знаний, доступ к урокам и обновлениям остается навсегда 💡

• Всю программу и отзывы смотрите в боте курса.
• Бонусный модуль про проектирование баз данных — нормализация, транзакции, основы DWH, индексы.
• Результат после прохождения курса: 15 рабочих проектов в портфолио.
• Доступ к чату учеников (общение, обмен опытом, помощь внутри сообщества)

🔹🔹 С чего начать?🔹🔹
С открытых бесплатных уроков по архитектуре и интеграциям в чат-боте курса. Переходите.
👇
@studyit_help_bot

Скидка на курс от канала —
1 500₽ по промокоду SYS до 30 января