Раздел III посвящён проектированию информационных систем и охватывает самые «технические» аспекты. Но при этом не нужно штудировать всё залпом — достаточно выбрать, что у вас болит.

Допустим, глава 16 описывает «техническое проектирование»: как внутри системы распределить логику, какие базы данных выбрать, зачем нужна контейнеризация. Если вы туманно представляете, чем занимаются архитекторы и почему обсуждают микросервисы или ER-диаграммы, то здесь вас ждёт прозрение: «Ах, вот оно что, так строится внутреннее моделирование!»

В 17-й главе речь идёт о более широком подходе к архитектуре: микросервисы, распределённые системы, слоистая архитектура, балансировщики, оркестрация — всё то, что часто звучит на командных встречах.

Глава 18 открывает тему интеграции: очереди сообщений, API, брокеры — если вы застряли в вопросах «какими форматами мы обмениваемся с внешними системами?» или «как мы синхронизируем редактуру данных?», вам обязательно туда.

И, наконец, глава 19 покажет, как оформлять задачи на разработку так, чтобы не остаться в недоумении: «Почему у нас всё время разные люди по-разному поняли одни и те же требования?»

Возможные инсайты: «Подождите, значит REST-подход и очереди — это не взаимоисключающие методы?» и «Вместо того, чтобы в четвёртый раз переписывать техническое задание для разработчиков, я могу наконец-то составить критерии приёмки».

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

• Какие сущности и классы будут внутри каждого модуля, какие методы и поля они содержат.
• Какое поведение «зашито» в объекты (паттерны, бизнес-правила).

• Если в системе используются микросервисы или компоненты с чёткими границами, нужно описать публичные методы, форматы сообщений.
• Для внутренней коммуникации (между подсистемами) может использоваться REST, gRPC, очереди (RabbitMQ, Kafka), или другие механизмы.

• Детальный Sequence Diagram: кто вызывает кого, с какими параметрами, какие данные возвращаются.
• Учёт ошибок, таймаутов, повторных запросов.

• Domain-Driven Design (DDD) — выделение агрегатов, репозиториев, сервисов;
• ORM-паттерны (например, Active Record, Repository);
• Паттерны интеграции (Saga, CQRS, Event Sourcing), если речь о сложной распределённой системе.

• Данные организованы в таблицы, строки, столбцы;
• Связи (relationship) между таблицами описываются ключами (foreign keys).

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

• SELECT, INSERT, UPDATE, DELETE, JOIN и другие конструкции.
• Большинство систем (MySQL, PostgreSQL, Oracle, Microsoft SQL Server) поддерживают стандартный SQL c некоторыми расширениями.

• ACID-свойства (Atomicity, Consistency, Isolation, Durability): обеспечивают надёжность при обновлениях.
• Важны для финансовых и критичных систем, где нельзя потерять данные или допускать «грязные» записи.

• Данные хранятся в виде JSON-подобных документов.
• Удобны для гибких схем, быстрых изменений структуры.

• Очень высокая скорость чтения/записи за счёт простой структуры: ключ → blob.
• Используются для кэшей, сеансов, высоконагруженных операций.

• Хранение данных в виде вершин и рёбер, эффективно для задач, связанных с графами (соцсети, маршруты, связи).
• Умеют быстро искать кратчайшие пути, общих соседей и т. д.

• Оптимизированы для аналитических запросов, больших объёмов данных.
• Данные хранятся по «столбцам», что упрощает агрегаты по большим массивам.

• Природы данных: табличные, документы, графы, ключ-значение;
• Требований к транзакционной целостности;
• Объёмов данных и нагрузки (read-heavy или write-heavy);
• Необходимости горизонтального масштабирования (которое легче обеспечить в NoSQL-системах).

1. Уточняет и консолидирует решения, которые предложили архитекторы и ведущие разработчики, следя за тем, чтобы они не расходились с системными требованиями и бизнес-логикой.
2. Поддерживает процесc моделирования (UML, Sequence Diagrams, схемы данных), фиксируя согласованные решения в документации (спецификациях, wiki, Confluence).
3. Участвует в выборе технологий (тип БД, паттерны взаимодействия, инструменты разработки), соотнося их с нефункциональными требованиями (производительность, надёжность, масштабируемость).
4. Обеспечивает понимание командой конечной цели и механики: если есть расхождения или нестыковки, вовремя поднимает вопрос и помогает найти компромисс.

В данной главе мы рассмотрим, что такое архитектура в контексте программного обеспечения (ПО) и решений (Solution Architecture), какие принципы и стили встречаются, и почему Systems Design (проектирование систем на более высоком уровне) сегодня приобретает особую актуальность.

1. Основные компоненты (building blocks): модули, подсистемы, сервисы, которые выполняют ключевые функции.
2. Взаимодействие между компонентами: протоколы, форматы данных, шины интеграции, события.
3. Принципы и паттерны: дизайн-принципы (SOLID, DRY), архитектурные паттерны (MVC, Layered Architecture, Hexagonal, микросервисы, и т. п.).
4. Нефункциональные характеристики (security, performance, reliability, availability), влияющие на выбор технологий и структуру решения.
5. Ограничения и допущения: технические (stack, окружение), бизнес-ограничения (сроки, бюджет), организационные (команда, политика, правовые аспекты).

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

• Выделение слоёв (Presentation, Business Logic, Data Access).
• Классический подход для многих enterprise-приложений.

• Предполагает набор loosely coupled сервисов, которые взаимодействуют через шину (ESB) или API.
• Часто применялась в крупных корпоративных системах.

• Разбиение функционала на небольшие, автономные сервисы, разворачиваемые и масштабируемые независимо друг от друга.
• Позволяет быстро развивать отдельные части системы, но накладывает overhead на интеграцию, мониторинг и DevOps-процессы.

• Компоненты реагируют на события, публикуемые в шине, вместо прямых вызовов друг друга.
• Удобно для асинхронной обработки, гибкого масштабирования и loosely coupled взаимодействия.

• Логика приложения разворачивается в виде функций (lambdas, cloud functions), которые запускаются «по событию» в облаке.
• Быстрое прототипирование, автоматическое масштабирование, но есть ограничения по длительности выполнения, мониторингу и привязке к облачному провайдеру.

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

• В распределённых системах возникает проблема согласованности (CAP-теорема): нельзя одновременно достичь идеальной консистентности, доступности и устойчивости к разделению сети.
• Приходится выбирать, где допустимы eventual consistency схемы, а где нужна строгая транзакционность.

• Логи и метрики могут быть разбросаны по разным узлам, нужна централизованная система мониторинга (Prometheus, Grafana, ELK-стек).

• Автоматизация деплоя (Docker, Kubernetes), балансировка нагрузки, резервирование.

• Пример: «Время отклика в 95% случаев не более 300 мс» — можно реализовать нагрузочный тест, который регулярно проверяет этот показатель. Если он не проходит, фитнес-функция «сигнализирует», что архитектура не соответствует требуемому уровню.
• Такие функции интегрируются в CI/CD pipeline, позволяя выявлять деградацию или нарушения SLA уже на этапах тестовых окружений.

• Component diagram, чтобы показать основные модули и связи;
• Deployment diagram, чтобы отразить физическое размещение (серверы, контейнеры).

• Уровень Context (общая среда и стейкхолдеры)
• Container (сервисы, БД, фронтенд)
• Component (внутренние компоненты каждого контейнера)
• Code / Class (детализация при необходимости).

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

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

• Это снижает связанность (coupling), позволяет обрабатывать некоторые операции в фоне (например, отправку уведомлений клиентам).
• Но требует проектировать шину или message broker (Kafka, RabbitMQ), учитывать порядок, дедупликацию, потенциально сложные отладку и трассировку (деньги списаны, но событие потерялось в шине?).

1. Инфраструктурные аспекты (серверы, сети, балансировщики, CDN, кластеры).
2. Data engineering: хранилища больших данных, стриминг, распределённые вычисления (Spark, Hadoop).
3. Сложные требования: горизонтальное масштабирование, обеспечение низкой задержки, геораспределённые инсталляции.
4. Бизнес-контекст: понимание объёмов данных, потенциального роста, сезонных пиков, рисков downtime.

1. Domain-Driven Design (DDD): фокус на моделировании бизнес-домена, выделении bounded context, Ubiquitous Language.
2. Event Storming: коллективная сессия, где участники «раскидывают» события на стикерах, чтобы понять основные процессы в бизнесе и выявить ключевые агрегаты.
3. Documenting Architecture: использование ADR, C4-модели, UML-диаграмм, Confluence-страниц для описания решений.
4. Threat Modeling (моделирование угроз): анализ уязвимостей, рисков безопасности на ранних этапах проектирования.
5. Performance Testing / Load Testing: прототипирование критических точек, проведение нагрузочных тестов, прежде чем реализовывать всё решение.
6. Proof of Concept (PoC): если есть сомнения насчёт выбранной технологии, лучше сделать небольшой эксперимент, чем «вкладываться» в масштабную реализацию и потом обнаружить несоответствия.

1. Основные архитектурные стили (монолит, микросервисы, события, SOA) и паттерны, чтобы взаимодействовать с архитекторами и объяснять бизнесу, почему выбран тот или иной подход.
2. Закон Конвея и влияние организации на архитектуру, а также необходимость согласовать архитектурные решения с реальным составом команд и практик.
3. Системный уровень (Systems Design), где учитываются распределённость, масштаб, требования по производительности и доступности, роль облачных технологий и больших данных.
4. Инструменты и практики, которые помогают поддерживать архитектуру в актуальном состоянии: C4-модель, ADR, Event Storming, PoC.

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

1. Внутренними системами в одной организации (ERP, CRM, складской учёт, бухгалтерия);
2. Системами разных компаний, которые являются партнёрами или клиентами (EDI, банковские шлюзы, платёжные сервисы);
3. Приложением и интернет-сервисом (OAuth-авторизация, использование внешних API для геолокации, платёжных транзакций и т. д.).

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

• Есть «центральный хаб», к которому подключаются все системы. Хаб отвечает за маршрутизацию, трансформацию форматов данных и т. д.
• Упрощает управление интеграцией, но может быть узким местом по производительности и надёжности.

• Эволюция Hub-and-Spoke, где шина (bus) обеспечивает масштабируемое и гибкое подключение сервисов. Может содержать механизмы оркестровки, преобразования сообщений, мониторинга.
• Использовалось в крупных корпоративных проектах (SOA), однако может стать «монолитным» решением, если не аккуратно проектировать.

• Каждая система предоставляет публичные/приватные API, через которые клиенты (в том числе другие системы) получают доступ к данным и функциям.
• Сегодня API-first подход очень распространён: он предполагает, что любая логика доступна через REST, GraphQL или gRPC.

• Системы публикуют события в шину (Kafka, RabbitMQ), а другие системы подписываются и реагируют на них. Асинхронное взаимодействие снижает связанность и даёт гибкость.
• Подходит для высоконагруженных и распределённых решений, но усложняет отладку, согласованность данных.

• Например, «Заказ», «Счёт», «Клиент», «Оплата».
• Выявить, как эти объекты «живут» в каждой из систем, в каких полях могут быть расхождения (дубли, разные форматы).

• Если запись о клиенте хранится в CRM, это «золотой источник» (single source of truth), а остальные системы должны обновляться из CRM.
• Избегать ситуации, когда несколько систем «параллельно» редактируют одну и ту же сущность, не синхронизируясь.

• Какие сценарии требуют «почти реального времени», а какие можно синхронизировать раз в час или сутки?
• Сколько записей или сообщений будет «проходить» через интеграцию (трафик)?

• Что, если одна из систем временно недоступна? Как обеспечить надёжность (очереди сообщений, ретрансляцию)?
• Как обрабатывать невалидные или конфликтующие данные?

• Важно понимать, что запрос может не дойти, а ответ может задержаться. Нужно продумывать таймауты и повторные попытки.
• Иногда требуется протокол с подтверждением (ACK), чтобы гарантировать доставку.

• Если данные распределены, может потребоваться eventual consistency (например, после обновления клиента в одной системе, другая узнаёт об этом событии через 5 секунд).
• В критичных сценариях (финансовые транзакции) нужно более жёсткое согласование (XA-транзакции или паттерны вроде Saga).

• Проверить, способен ли брокер сообщений или API-шлюз выдержать пик («чёрную пятницу», сезонную нагрузку).
• Эмулировать сценарии, где много параллельных вызовов.

• Передача данных может требовать шифрования (TLS), аутентификации (OAuth 2.0, JWT), строгого контроля доступа.
• Внешние API нужно защищать от DDoS, SQL/JSON-инъекций.

1. Интеграция: другие системы могут подключаться к вашему решению без прямого доступа к внутренней структуре БД.
2. Безопасность: API может давать доступ только к определённым методам и данным, сохраняя логику авторизации.
3. Расширение: если у системы есть стабильное API, партнёры и разработчики могут создавать надстройки, приложения, интеграции.
4. Разделение ответственности: фронтенд (UI) отделён от бэкенда, который общается по API. Это упрощает развитие и тестирование.

• REST на HTTP с JSON — самый популярный и простой вариант.
• SOAP — для строго типизированных и более формальных контрактов (часто используется в legacy-системах).
• GraphQL — гибкая схема, клиент сам выбирает, какие поля получать.
• gRPC — двоичный высокопроизводительный протокол с поддержкой stream.

• Единобразие в именах эндпоинтов (например, /api/v1/orders, /api/v1/customers).
• Чёткое разграничение (GET/POST/PUT/DELETE).
• Описание в OpenAPI (Swagger), чтобы другие могли легко понять спецификацию.

• Возможность обновлять API, не ломая старый функционал.
• Пример: /api/v1/... и /api/v2/... или параметр в заголовках.

• Авторизация по токенам (JWT, OAuth 2.0), HTTPS, ограничение запросов (rate limiting).
• Логирование и аудит (кто, когда, что вызывал).

1. Асинхронное взаимодействие: отправитель не ждёт немедленного ответа, просто публикует сообщение в очередь или топик.
2. Декуплинг: если получатель недоступен, сообщение может лежать в очереди и будет обработано, когда потребитель появится.
3. Масштабируемость: можно распределять нагрузку среди многих потребителей.
4. Гибкую маршрутизацию: можно настроить фильтрацию, трансформацию сообщений, привязку к конкретным очередям.

• JSON, Avro, Protobuf, бинарные пакеты.
• Чётко зафиксировать схемы: какие поля, типы данных.

• В RabbitMQ есть exchange (fanout, direct, topic) и очереди; в Kafka есть темы (topic), партиции.
• Определить ключи маршрутизации, чтобы правильный потребитель получал нужные сообщения.

• Если сообщение некорректно, куда оно уходит (dead-letter queue)?
• Сколько раз делаем повторную попытку?

• В асинхронной среде сообщение может поступить несколько раз, нужно уметь распознавать «дубликаты», чтобы не создавать лишних операций (например, дважды списывать средства).

• Конфигурация прав доступа, шифрование трафика (SSL), мониторинг очередей.

1. Выявить бизнес-процессы и объекты данных, которые пересекаются между системами.
2. Определить необходимую частоту, формат и режим обмена (синхронный REST/GraphQL, асинхронный событийный).
3. Разработать спецификации API, продумать протоколы, шифрование, аутентификацию и прочие аспекты.
4. Протестировать и оценить надёжность, производительность, согласованность распределённых данных.

При грамотном подходе к интеграции удаётся создать целостный IT-ландшафт, в котором информация свободно «переходит» от одной системы к другой, а бизнес-процессы автоматизируются «от конца до конца», без ручного дублирования и ошибок.

В этой главе мы рассмотрим основные принципы и подходы к постановке задач в рамках проектов, какие форматы используются в разных методологиях (Agile, Waterfall), как описывать задачи и критерии приёмки, а также как организовать эффективную коммуникацию вокруг задач.

1. Сокращение двусмысленности. Чёткое описание задачи уменьшает риск, что разработчик поймёт её «по-своему» и будет делать не то, что ожидает бизнес.
2. Повышение прозрачности. Видно, какие задачи действительно в работе, какие уже сделаны, какие заблокированы.
3. Удобство планирования. Когда задача хорошо описана, её проще оценить по трудоёмкости, спланировать в спринте или в классическом графике проекта.
4. Основа для тестирования. Если критерии приёмки прописаны, тестировщики могут сразу подготовить чек-листы и тест-кейсы.

Грамотно составленная задача переводит требования (часто объёмные) в конкретный шаг разработки, понятный исполнителю и проверяемый приёмкой.

• Часто оформляются спецификации и технические задания (ТЗ), где каждая функция описана формально.
• Задачи для разработчиков могут выделяться из этого ТЗ с указанием разделов и пунктов («Реализовать пункт 3.2.1: модуль авторизации»).
• Изменения проходят формальный Change Request; каждой правке может соответствовать новая «задача на доработку».

• Используются user stories, разбитые на небольшие задачи (sub-tasks или technical tasks).
• Есть бэклог (backlog), где задачи лежат по приоритетам.
• В Scrum задачи берутся в спринт, обсуждаются на планировании, привязываются к конкретным исполнителям.
• Изменения более гибкие: может добавить или переформулировать задачу в бэклоге, если меняются требования.

• Короткое название, описывающее суть задачи: «Реализовать фильтр заказов по статусу», «Добавить отправку e-mail при регистрации».

• Детальное пояснение, что нужно сделать.
• Может включать скриншоты, диаграммы, ссылки на прототипы, если речь идёт об интерфейсе.
• В Agile-формате часто указывают User Story: «Как [роль], я хочу [действие], чтобы [результат]».

• Чёткий список пунктов, по которым понимаем, что задача выполнена правильно.
• Пример:

• Acceptance Criteria служат базой для QA-тестов.

• Технические детали (какой API-эндпоинт трогаем, какие таблицы в БД).
• Ссылки на связанные задачи или эпики.
• Зависимости (к примеру, «Нельзя начинать, пока не реализована авторизация», «Работаем вместе с задачей DEV-123»).

• В Scrum/Agile часто используют Story Points для оценки.
• Приоритет: Must, Should, Could или High, Medium, Low.

• Избегать «мешка» разных доработок. Лучше разделить задачи, если они касаются разных частей системы или решают разные проблемы.
• Так легче тестировать и оценивать результат.

• В Agile-командах бывает соглашение: задача не берётся в спринт, пока не прописаны критерии приёмки, нет необходимых макетов, не ясны зависимости.
• Это снижает риск, что задача «зависнет» в процессе разработки из-за неясных деталей.

• Писать на языке, понятном разработчику и тестировщику, избегать лишней «воды».
• Если есть сложная логика, лучше приложить диаграмму (Sequence, Activity), чем пытаться описать её длинным текстом.

• Если по ходу выясняется, что задача меняется, надо обновить описание, а не держать важные детали в чатах.
• Так остальные члены команды (тестировщик, технический писатель) не будут работать с устаревшей информацией.

• Часто проще «пройтись» по задаче на коротком митинге/колле, чем писать длинную переписку.
• Аналитик может показать прототип, прояснить нюансы, ответить на вопросы команды.

1. Ревью кода (Code Review) — разработчики смотрят друг за другом, нет ли нарушений стандартов, ошибок.
2. Тестирование — QA-инженер или сам аналитик проверяет, соответствует ли результат требованиям, не сломалось ли что-то ещё.
3. Демонстрация — если в конце спринта или итерации, на Review показывают, как работает реализованная задача.
4. Фидбэк — если есть пожелания или обнаруженные неточности, они могут оформляться в виде новой задачи, если не являются критической ошибкой.

1. Эффективность разработки — меньше переделок и недопонимания;
2. Скорость и прозрачность — команда чётко видит, что делать, как это проверить, и когда задача считается выполненной;
3. Качество конечного продукта — если критерии приёмки прописаны грамотно, система в итоге удовлетворяет потребностям пользователей и бизнес-заказчиков.