System Design¶
Ни один стандарт не диктует канонический чек-лист для System Design, но есть базовая норма ISO/IEC/IEEE 42010:2022.
- Stakeholder - Любой человек / роль, кому не всё равно, что будет с системой (Пользователь, Product-owner, DevOps, регулятор).
- Concern - То, что волнует конкретного stakeholder’а («Сайт должен держать 5 000 rps», «Данные GDPR не утекут»).
- Viewpoint - Шаблон, как показывать систему, чтобы ответить на группу concerns («Deployment Viewpoint» = диаграмма узлов + сети).
- View - Реализованный документ/диаграмма для вашей системы, созданный по выбранному viewpoint’у ( Kubernetes-диаграмма вашего прод-кластера (deployment view)).
Слои архитектурного дизайна¶
| № | Срез (concern) | Вопрос, на который отвечает | Типовые варианты / решения |
|---|---|---|---|
| 1 | Deployment/Topology (Macro-Architecture) | Описывает грубое разбиение системы на процессы/службы и их расположение в инфраструктуре. Сколько исполняемых единиц? Как они взаимодействуют между собой и где развёрнуты? как расставлены? |
Монолит, Слойный монолит / 3-Tier, SOA (Service-Oriented Architecture), Microservices, Self-Contained Systems (SCS), Backend-for-Frontend (BFF), Event-Driven / EDA (в т. ч. CQRS + Event Sourcing), Serverless / FaaS, Actor-Model Cluster, Pipes & Filters / Data-Pipeline |
| 2 | Communication & API Style (Macro-Architecture) | Как сервисы общаются и описывают контракты? Описывает: Модель взаимодействия, Форматы сообщений | REST, RPC, gRPC GraphQL, SOAP, WebSockets |
| 3 | Data Architecture | Как храним данные? | RDBMS (OLTP) • NoSQL (KV, Doc, Wide-col) • TimeSeries • Graph DB • Polyglot • Sharding • Replication • Caching (Redis) • Event Store |
| 4 | Consistency & Transactions | Какая модель целостности? | ACID • BASE • Eventual Consistency • Saga / Outbox • Two-Phase Commit |
| 5 | Scaling & Performance | Как выдерживаем нагрузку? | Vertical vs Horizontal • Load Balancer • CDN • Partitioning • Async queues • Back-pressure |
| 6 | Fault-Tolerance & Resilience | Как справляемся со сбоями? | Retries • Circuit Breaker • Bulkhead • Idempotency • Chaos Testing |
| 7 | Security Architecture | Кто и как имеет доступ? | TLS, mTLS • OAuth2/OIDC • API-Keys • WAF • Secrets Mgmt • Zero Trust |
| 8 | Observability | Как мы видим, что внутри? | Structured Logs • Metrics • Tracing • Profiling • Health Checks |
| 9 | Code-Level (Micro-Architecture) | Как организован исходный код отдельного сервиса? | Layered • MVC • MVP • MVVM • Hexagonal • Clean / Onion • DDD modules |
| 10 | Build & Delivery | Как код превращается в релиз? | CI/CD pipeline • GitOps • Canary • Blue-Green • Feature Flags |
| 11 | Infrastructure Platform | На чём всё крутится? | Bare-metal • VMs • Containers (Docker) • Orchestration (K8s, Nomad) • Cloud PaaS |
| 12 | Governance & Compliance | Какие нормы и процессы? | Docs, ADR, API-Versioning, RBAC, Audit, GDPR |
4+1 View Model - Классика UML¶
- Отражает разные углы зрения основных стейкхолдеров (бизнес, разработка, эксплуатация) с минимумом документов.
- Расширяемость. 42010 разрешает добавлять viewpoint’ы. Если Security или Data Governance требуют отдельной детализации — проект добавит «Security View» или «Data View», но базовые пять никто не убирает.
4 + 1 не «обрезает» остальные срезы, а группирует их в пять универсальных проекций. Если проекту нужны дополнительные детали (например, отдельный Security View или Compliance View), их добавляют как дополнительные viewpoint’ы в рамках того же ISO 42010 процесса.
| View (4+1) | Какие из ваших concerns туда попадают | Почему именно здесь |
|---|---|---|
| Logical View (доменные подсистемы и их данные) |
Context / Stakeholders – очерчивает границы. • Communication & API Style – логические контракты между подсистемами. • Data Architecture – какие данные у какой подсистемы. • Consistency & Transactions – инварианты домена на логическом уровне. • (Части Security / Governance) – бизнес-правила доступа, GDPR-«что» (не «как»). |
Срез показывает что делает система и какие данные ею управляют, не вдаваясь в код или железо. |
| Development View (организация исходного кода и сборки) |
Code-Level (микро-архитектура) – слои, модули, DDD пакеты. • Build & Delivery – CI/CD, ветки, feature flags. • Governance & Compliance – версионирование API, ADR, лицензии кода. |
Отвечает «как разработчики видят проект в IDE и в репозитории». |
| Process View (рантайм-поведение, параллелизм) |
Scaling & Performance – пулы, очередь, latency SLO. • Fault-Tolerance & Resilience – retries, circuit breakers. • Consistency & Transactions – фазы Saga / 2PC во время исполнения. • Security (поток токенов, ACL runtime). • Observability – логи, трейсинг, алерты на процессы. • Transport / Protocol – синхр./асинхронные вызовы, time-outs. |
Показывает что происходит при выполнении сценария: очереди, потоки, ошибки. |
| Physical View (развёртывание на инфраструктуре) |
Deployment / Topology – контейнеры, ВМ, кластера. • Infrastructure Platform – K8s, bare-metal, cloud PaaS. • Transport / Protocol – реальные порты, TLS, LB. • Security (сетевые сегменты, mTLS). • Observability (метрики узлов). • Scaling / Resilience (авто-скейлинг групп, DR-зоны). |
Отвечает «где именно крутится» и «какие сети / узлы связаны». |
| + 1 Scenarios / Use Cases | Сквозные бизнес-потоки, взятые из Context / Stakeholders; на практике — 5-10 секвенс-диаграмм или текстовых юз-кейс-шагов. | Проверяет, что четыре вида выше действительно совместно решают задачи. |