Перейти к содержанию

TODO: Roadmap

1. Requirements Engineering

  1. Инициация сбора требований 1.1. Определение целей и контекста проекта 1.2. Идентификация стейкхолдеров 1.3. Сбор исходных документов и бизнес-описаний

  2. Выявление требований (Elicitation) 2.1. Интервью с заказчиком и пользователями 2.2. Анкеты, опросы, фокус-группы 2.3. Наблюдение за текущими процессами (shadowing) 2.4. Workshop / JAD-сессии

  3. Анализ и категоризация 3.1. Разделение на функциональные (FR) и нефункциональные (NFR) требования 3.2. Приоритизация (MoSCoW, Kano) 3.3. Уточнение бизнес-правил и ограничений

  4. Моделирование требований 4.1. Use Case-диаграммы (UML) 4.2. User Story Mapping / Story Board 4.3. BPMN / Activity Diagrams

  5. Документирование в SRS 5.1. Введение и Scope 5.2. FR: описание сценариев с уникальными ID 5.3. NFR: производительность, безопасность, масштабируемость 5.4. Интерфейсы: UI, API, Hardware, Network 5.5. Бизнес-правила и допущения

  6. Валидация и согласование 6.1. Review-сессии с заказчиком 6.2. Прототипы / Mock-up 6.3. Финальное утверждение SRS

  7. Управление требованиями 7.1. Версионирование SRS 7.2. Обработка Change Requests 7.3. Traceability Matrix (связь требований → дизайн → тесты)

2. System Design

  1. Подготовка и входные данные 1.1. Утверждённые FR/NFR из SRS 1.2. Технические ограничения и предпосылки 1.3. KPIs: RPS/QPS, latency, SLA

  2. High-Level Architecture 2.1. Выбор стиля: монолит ↔ микросервисы ↔ SOA 2.2. Слоистая архитектура (Presentation, Business, Data) 2.3. C4 Model: Context & Container Diagrams 2.4. Разграничение Bounded Contexts (DDD)

  3. Компоненты и интеграция 3.1. API Gateway, Load Balancer 3.2. Базы данных: SQL vs NoSQL, репликация, шардирование 3.3. Кэш (Redis/Memcached), CDN 3.4. Messaging (Kafka, RabbitMQ)

  4. Нефункциональные решения 4.1. Масштабируемость: горизонтальная vs вертикальная 4.2. Отказоустойчивость: Health Checks, Failover, Replicas 4.3. Безопасность: TLS, OAuth2/JWT, WAF 4.4. Производительность: кеширование, CDN, тонкие клиенты

  5. Detailed Design 5.1. UML-диаграммы классов и последовательностей 5.2. ER-диаграмма базы данных, индексы 5.3. Проектирование API (REST/GraphQL/gRPC) 5.4. Стратегии кеширования и обработки ошибок (retry, circuit breaker)

  6. Инфраструктура и деплой 6.1. Docker-контейнеризация, Dockerfile 6.2. Оркестрация: Kubernetes / Docker Swarm 6.3. CI/CD pipeline: build → test → deploy → rollback 6.4. Мониторинг и логирование (Prometheus, ELK, Grafana)

  7. Верификация дизайна 7.1. PoC / Spike solutions для критичных компонентов 7.2. Архитектурные ревью (ADR) 7.3. Нагрузочное и security-тестирование

3. Project Management

  1. Инициация проекта 1.1. Project Charter (цели, обоснование) 1.2. Определение стейкхолдеров 1.3. Ключевые риски и допущения

  2. Планирование 2.1. Scope Definition & WBS 2.2. Оценка ресурсов и сроков (PERT, Delphi, Expert Judgment) 2.3. График: Gantt Chart, Critical Path Method 2.4. Бюджет и план закупок 2.5. Risk Management Plan 2.6. Communication Plan

  3. Исполнение 3.1. Team Formation & Roles (PO, PM, Dev Team) 3.2. Управление ресурсами и задачами (Task Tracking) 3.3. Code Review & QA практики 3.4. Управление изменениями (Change Requests)

  4. Мониторинг & контроль 4.1. Earned Value Management (EV, PV, AC, SPI, CPI) 4.2. Status Reporting (Dashboards, Status Reports) 4.3. Управление рисками (Risk Register обновления) 4.4. Quality Control (тестирование, инспекции)

  5. Закрытие проекта 5.1. Acceptance Testing и передача продукта 5.2. Lessons Learned / Post-mortem 5.3. Архивация документации 5.4. Закрытие контрактов и освобождение ресурсов

Java: темы к разбору

Многопоточность

  • Многопоточность. Класс Thread, интерфейс Runnable. Модификатор synchronized интерфейсы Lock и Condition
  • Классы-сихронизаторы из пакета java.util.concurrent
  • Модификатор volatile. Атомарные типы данных и операции
  • Коллекции из пакета java.util.concurrent
  • Интерфейсы Executor, ExecutorService, Callable, Futur
  • Пулы потоко

Паттерны

  • Шаблоны проектирования: Decorator, Iterator, Factory method, Command, Flyweight, Interpreter, Singleton, Strategy, Adapter, Facade, Proxy
  • GRASP & GoF Design patterns
  • Enterprise Patterns

Сети: темы к разбору

Контекст. Keenetic Giga не тянет то, что нужно для работы. Клиент Xray для VLESS ставится только через сторонний XKeen поверх Entware и ломается после обновлений прошивки. Маршрутизация по доменам в разные VPN слабая: DNS-маршруты только добавляют маршруты, политика одна на устройство, GeoIP нет. Веб-админка подходит для дома, для работы нет. Вопрос - закроет ли это корпоративное железо: MikroTik, Cisco, стоечные маршрутизаторы и коммутаторы.

Предварительный вывод из разбора 18.10.2026: VLESS и «домен → нужный VPN» решает не класс железа, а прокси-движок на Linux (sing-box, Xray). Cisco, Juniper и Eltex этого не умеют вообще. MikroTik даёт профессиональную сеть: VLAN, несколько таблиц маршрутизации, CLI с /export. Xray на нём живёт только в контейнере. Рабочая схема - Linux-шлюз с sing-box для прокси и MikroTik или Keenetic для самой сети.

Основы

  • Чем отличается маршрутизатор от коммутатора. Частично есть в network-devices, разделы «Маршрутизатор» и «Сравнение» - проверить и дополнить
  • Разница L2 и L3 коммутатора. В network-devices пока два пункта в «Виды коммутаторов» и таблица L3-коммутатор против маршрутизатора - расписать отдельно: что добавляет L3 (SVI, маршрутизация между VLAN в ASIC, ACL, статика и OSPF), что такое L2+ и L3-lite

Корпоративное железо против домашнего

  • Keenetic против MikroTik, Cisco, Eltex, OpenWrt и Linux-шлюза: что умеет каждый, как управляется, что с поддержкой в РФ
  • Что умеет корпоративный маршрутизатор: несколько таблиц маршрутизации, policy-based routing, BGP и OSPF, полноценный firewall, несколько каналов с переключением, QoS, NetFlow
  • Что умеет управляемый коммутатор: VLAN-транки, LACP, PoE-бюджет, STP, зеркалирование портов, 802.1X, SFP+
  • Интерфейсы управления: WinBox, WebFig и CLI RouterOS, /export в git, REST API, CLI Cisco IOS, Ansible
  • Стоечное железо MikroTik: маршрутизаторы CCR и RB5009, коммутаторы CRS326 и CRS328 с PoE

Маршрутизация по доменам и прокси

  • Почему маршрутизация по доменам на роутере неточная: CDN на общих IP, DoH мимо роутера, устаревшие адрес-листы
  • Как это делает прокси: сниффинг SNI, FakeIP, правила по домену и GeoIP в sing-box и Xray
  • MikroTik: адрес-листы через DNS (match-subdomain=yes address-list=), mangle, отдельные таблицы маршрутизации, конфликт FastTrack с маркировкой
  • Контейнеры в RouterOS v7: device-mode, sing-box и Xray на RB5009
  • OpenWrt и Podkop: точечная маршрутизация доменов на VLESS и WireGuard
  • XKeen на Keenetic: что умеет и почему хрупкий

Security и low-level

  • https://timcore.ru/2021/02/24/1-kali-linux-dlja-nachinajushhih-urok-1-osnovy-setej/
  • https://makelinux.github.io/kernel/map/
  • https://kernelnewbies.org/KernelHacking
  • https://bootlin.com/doc/training/linux-kernel/linux-kernel-slides.pdf
  • https://wiki.osdev.org/Expanded_Main_Page
  • https://www.kernel.org/doc/html/v4.16/process/howto.html
  • https://uneex.ru/
  • https://habr.com/ru/companies/sberbank/articles/353746/

Ссылки к разбору

  • https://github.com/mjhea0/awesome-fastapi
  • https://github.com/wiseaidev/awesome-fastapi
  • https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/nginx.html
  • https://dev.to/envoy_/awesome-clones-32l8
  • https://github.com/humiaozuzu/awesome-flask
  • https://github.com/aimclub/open-source-ops?tab=readme-ov-file

Источники

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

Организация и домен

  • Melvin Conway — «How Do Committees Invent?» (Datamation, 1968): откуда растёт Conway's Law. Эмпирическое наблюдение, не предписание: структура системы повторяет структуру коммуникаций команд. Имя «закон» навесил позже Fred Brooks в «The Mythical Man-Month» (1975). Inverse Conway Maneuver — поздняя надстройка, сам Conway его не предлагал.
  • Eric Evans — «Domain-Driven Design» (2003): bounded context как граница модели и ubiquitous language. Не маппится один-к-одному ни на microservice, ни на команду, ни на subdomain — это граница смысла, не deployment unit.

Стили деплоя

  • Martin Fowler — «MonolithFirst» (2015, martinfowler.com): начинай с monolith, режь на сервисы, когда границы понятны. Дефолт с исключениями, не закон. Здесь же канонично оформлена рамка monolith vs microservices — слово monolith это retronym из эпохи микросервисов, а не «грязный код».
  • James Lewis & Martin Fowler — «Microservices: a definition of this new architectural term» (2014, martinfowler.com): каноническое определение стиля. Акцент на independent deployability, decentralized data и organization around business capabilities — не на размере. Термин устаканили на воркшопе архитекторов под Венецией: май 2011, добили май 2012.
  • Mary Shaw & David Garlan — «Software Architecture: Perspectives on an Emerging Discipline» (1996): ранний каталог стилей, где разведены logical layers и physical tiers. Layered живёт внутри одного process, three-tier — это отдельные deployable tiers. Не синонимы.
  • Yefim Natis & Roy Schulte (Gartner) — «Service Oriented Architecture» (1996): первоисточник термина SOA. Это философия дизайна, не стек: SOAP/WSDL/WS-* и тяжёлый ESB — одна (часто критикуемая) реализация, не определение.
  • Simon Brown — доклад «Modular Monoliths» (Devoxx 2016) + simonbrown.je: modular monolith как один deployable с принудительными границами модулей внутри. Не «monolith с папками» и не обязательно ступенька к микросервисам — может быть валидным конечным состоянием. Та же идея — «The Missing Chapter» в «Clean Architecture» Роберта Мартина (2017).
  • Stefan Tilkov / INNOQ — Self-Contained Systems, scs-architecture.org (~2015): SCS как автономный вертикальный срез с собственным UI, логикой и данными. Намеренно крупнее микросервисов (мало на систему), интеграция через UI/links и async, а не синхронный RPC.
  • Mike Roberts & John Chapin — «Serverless Architectures» (2016/2018, martinfowler.com): разбор serverless/FaaS как стиля. Серверы никуда не делись — их прячет и автоскейлит провайдер. Отправная точка по индустрии — запуск AWS Lambda, ноябрь 2014.
  • Carl Hewitt, Peter Bishop, Richard Steiger — «A Universal Modular ACTOR Formalism for Artificial Intelligence» (IJCAI, 1973): первоисточник actor model. Никаких гарантий порядка, доставки или распределённых транзакций из коробки — это потом дописали фреймворки, и location transparency сетевые сбои не отменяет.
  • Frank Buschmann et al. — «Pattern-Oriented Software Architecture, Vol. 1» (1996), паттерн «Pipes and Filters»: поток данных через цепочку независимых stateless-фильтров. Концептуальные корни — Unix pipes (Douglas McIlroy, Bell Labs, реализация 1973). Современные распределённые стримы переиспользуют идею, но добавляют parallelism, backpressure, fault tolerance.

Миграция и анти-паттерны

  • Martin Fowler — «StranglerApplication», позже «Strangler Fig Application» (2004, martinfowler.com): постепенная замена legacy по краям, обе системы крутятся параллельно. Не big-bang переписывание. Имя дрейфовало от Strangler Application к Strangler Fig.
  • Ben Christensen — доклад «Don't Build a Distributed Monolith» (Microservices Practitioner Summit, январь 2016): популяризация термина distributed monolith. Раньше уже встречался у Derek Gottlieb («Distributed Monoliths», блог, июнь 2015), так что Christensen популяризировал, а не придумал. Беда не в числе сервисов, а в coupling: дробление без independent deployability и decoupled data даёт худшее с обеих сторон.
  • Sam Newman — «Building Microservices» и «Monolith to Microservices» (O'Reilly, 2019): практика декомпозиции, BFF, и дальнейшая раскрутка термина distributed monolith.

Интеграция, gateway, frontend

  • Gregor Hohpe & Bobby Woolf — «Enterprise Integration Patterns» (2003): каталог messaging-паттернов (channels, routers, translators, endpoints). Vendor-neutral словарь, не привязан к конкретному ESB и не только про legacy SOA — ложится и на современные event/stream системы.
  • Phil Calçado — «The Back-end for Front-end Pattern (BFF)» (2015, philcalcado.com): практика SoundCloud (идею Calçado приписывает коллеге Lukasz Plotnicki). Один BFF на каждый distinct UX (iOS, Android, web), тонкий слой агрегации и трансляции — не общий god-gateway и не место для domain logic.
  • Chris Richardson — microservices.io и «Microservices Patterns»: каталог паттернов, включая API Gateway (~2014, корни в reverse-proxy и SOA gateway). Не путать gateway с load balancer или service mesh, и не раздувать его в «God gateway» с бизнес-логикой.

Данные, события, согласованность

  • Roy Schulte и аналитики Gartner — Event-Driven Architecture (~2003): компоненты общаются, порождая и реагируя на события, а не через прямой request/response. Единого seminal paper нет, идея кодифицирована в т.ч. в Hohpe & Woolf. EDA это не «просто message queue»; thin event notification, event-carried state transfer и event sourcing часто путают.
  • Greg Young — CQRS (~2010): разделение моделей для команд и запросов. Опирается на Command-Query Separation Бертрана Мейера («Object-Oriented Software Construction», 1988). Разделение на уровне модели, может быть in-process — не обязательно две базы плюс event sourcing. Ключевая популяризация — bliki-статья Фаулера «CQRS» (2011).
  • Martin Fowler & Greg Young — Event Sourcing (Fowler bliki, 2005; практика Young ~2006–2010): источник истины это лог событий, текущее состояние выводится реплеем. С CQRS независимы, хоть и часто ходят вместе. Лог это не мутабельная audit-таблица — versioning событий и цена реплея всплывают позже.
  • Hector Garcia-Molina & Kenneth Salem — «Sagas» (SIGMOD '87): первоисточник. Long-lived transaction как цепочка локальных с компенсациями. ACID между сервисами не даёт — только eventual consistency через компенсацию, не isolation. Оригинал 1987 года был про long-lived DB-транзакции; распределённая orchestration/choreography — поздняя переинтерпретация.

Если этот раздел расходится с тем, что в основном тексте (микросервисы, Communication & API Style) — верь тексту и правь этот список, а не наоборот.

Главное правило: на оси «один deployable ↔ много» тебя двигают масштаб и оргструктура (закон Конвея), не мода. Дефолт — modular monolith. Каждый сетевой разрез покупаешь ценой latency, частичных отказов и eventual consistency — режь по bounded context и ровно там, где боль уже реальная.