System Design¶
| Слой архитектурного дизайна | Решаемый вопрос |
|---|---|
| 1. Требования | |
| Требования | [ > ] |
| 2. Архитектура | |
| (Domain) Classification | [ > ] Какого класса каждая область -- CRUD, домен, интеграция, вычисления? |
| (Domain) Strategic DDD | [ > ] Из каких предметных областей состоит система и где границы смысла? |
| (Macro-Arch) Deployment / Topology | [ > ] Сколько исполняемых единиц, где развёрнуты и что оправдывает разделение? |
| (Macro-Arch) Communication & API Style | [ > ] Как сервисы общаются и описывают контракты? |
| (Macro-Arch) Data Architecture | [ > ] Как храним данные и кто ими владеет? |
| (Micro-Arch) Code: Package Structure | [ > ] Чем определён верхний уровень пакетов -- ролями или доменом? |
| (Micro-Arch) Code: Business Logic | [ > ] Где живёт бизнес-логика и где границы агрегатов? |
| (Micro-Arch) Code: Core Isolation | [ > ] Как ядро защищено от фреймворка и БД? |
| (Micro-Arch) Code: Refinements | [ > ] Разделены ли чтение и запись? Как связаны модули внутри процесса? |
| (Micro-Arch) Presentation | [ > ] Как организован UI-слой клиента? |
| Cross-Cutting Concerns | Транзакции, ошибки, валидация, тесты, идемпотентность -- как реализованы? |
| Infrastructure Platform | На чём всё крутится? |
| 3. Свойства | |
| Consistency & Transactions | [ > ] Какую модель целостности выбираем и как обеспечиваем? |
| Scaling & Performance | Как выдерживаем нагрузку? |
| Fault-Tolerance & Resilience | Как справляемся со сбоями? |
| Security Architecture | Кто и как имеет доступ? |
| Observability | Как мы видим, что внутри? |
| Build & Delivery | Как код превращается в релиз? |
| Governance & Compliance | Какие нормы и процессы? |
Как это нарисовать и Кому показать?¶
4+1 View Model - Классика UML¶
Филипп Крухтен, Rational, 1995. Ответ на проблему: у архитектуры нет одной правильной диаграммы, потому что у неё разные читатели с разными вопросами.
- Отражает разные углы зрения основных стейкхолдеров (бизнес, разработка, эксплуатация) с минимумом документов.
- Расширяемость. 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 секвенс-диаграмм или текстовых юз-кейс-шагов. | Проверяет, что четыре вида выше действительно совместно решают задачи. |