System Design Space

    Глава 49

    Обновлено: 15 февраля 2026 г. в 21:30

    Fundamentals of Software Architecture (short summary)

    Прогресс части0/14

    Источник

    Обзор книги

    Глава основана на этой статье

    Читать статью

    Fundamentals of Software Architecture (Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы)

    Авторы: Mark Richards, Neal Ford
    Издательство: O'Reilly Media, 2020
    Объём: 432 страниц

    Архитектурные характеристики, стили (Layered, Microservices, Event-Driven) и soft skills архитектора от Mark Richards и Neal Ford.

    Fundamentals of Software Architecture — оригинальная обложкаОригинал
    Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы — переводПеревод

    Структура книги

    Книга разделена на три части, каждая из которых раскрывает различные аспекты роли архитектора:

    Часть I: Основы

    Архитектурное мышление, модульность, характеристики архитектуры и методы их измерения.

    Часть II: Стили архитектуры

    Layered, Pipeline, Microkernel, Service-Based, Event-Driven, Space-Based, Microservices и другие.

    Часть III: Soft Skills

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

    Статья

    Architectural Characteristics and Trade-offs

    Детальный разбор характеристик архитектуры и принципов выбора компромиссов

    Читать статью

    Часть I: Архитектурное мышление

    Architecture Characteristics (ilities)

    Операционные
    Availability
    Доступность системы (99.9%, 99.99%)
    Reliability
    Надёжность и устойчивость к сбоям
    Performance
    Время отклика и пропускная способность
    Scalability
    Способность масштабироваться под нагрузкой
    Структурные
    Modularity
    Разделение на независимые модули
    Extensibility
    Лёгкость добавления новой функциональности
    Maintainability
    Простота поддержки и изменений
    Testability
    Возможность тестирования компонентов
    Кросс-функциональные
    Security
    Защита от угроз и уязвимостей
    Accessibility
    Доступность для всех пользователей
    Usability
    Удобство использования
    Agility
    Скорость адаптации к изменениям

    Ключевой инсайт: Архитектор должен выбрать 3-5 ключевых характеристик для системы. Попытка оптимизировать всё приводит к «generic architecture» — посредственному решению без явных преимуществ.

    Связь архитектуры с характеристиками

    Design
    ExplicitImplicit
    Non-design
    Определяет операционные критерии успеха
    Structural
    Влияет на структуру решения
    Архитектурное
    мышление
    Architecture Characteristics

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

    Explicit (явные)
    Implicit (неявные)

    Модульность и связанность

    Метрики модульности
    Cohesion
    Насколько связаны элементы внутри модуля (высокая = хорошо)
    Coupling
    Зависимость между модулями (низкая = хорошо)
    Connascence
    Степень изменений при модификации (статическая vs динамическая)
    Abstractness
    Соотношение абстракций к конкретным реализациям
    Distance from Main Sequence

    Метрика оценки качества модуля через баланс абстрактности и стабильности:

    D = |A + I - 1|

    A = Abstractness, I = Instability. Чем ближе D к 0, тем лучше.

    Main Sequence и зоны риска

    Zone of PainZone of UselessnessMain SequenceI: InstabilityA: Abstractness(0,0)(1,0)(0,1)(1,1)
    Main Sequence

    Идеальная диагональ: баланс между абстрактностью и стабильностью. Формула: D = |A + I - 1|

    Zone of Pain

    Конкретные и стабильные компоненты (A≈0, I≈0). Сложно менять, так как много зависимостей.

    Zone of Uselessness

    Абстрактные и нестабильные компоненты (A≈1, I≈1). Абстракции без реализаций.

    Типы Connascence

    Static
    Легче рефакторить
    Name
    Зависимость от имени сущности
    Type
    Зависимость от типа данных
    Meaning
    Зависимость от семантики значений
    Algorithm
    Зависимость от алгоритма
    Position
    Зависимость от порядка элементов
    Dynamic
    Сложнее рефакторить
    Execution
    Зависимость от порядка выполнения
    Timing
    Зависимость от времени выполнения
    Value
    Зависимость от конкретных значений
    Identity
    Зависимость от идентичности объекта
    Рефакторить проще
    Связанность сильнее

    Часть II: Архитектурные стили

    Монолитные архитектуры

    Layered Architecture
    • Presentation → Business → Persistence → Database
    • Простота понимания и разработки
    • Sinkhole anti-pattern
    Pipeline Architecture
    • Pipes and Filters паттерн
    • ETL, data processing pipelines
    • Unix philosophy
    Microkernel Architecture
    • Core system + plug-in components
    • IDE, браузеры, Eclipse
    • Расширяемость без изменения ядра

    Распределённые архитектуры

    Service-Based Architecture

    «Золотая середина» между монолитом и микросервисами:

    4-12 сервисов
    Крупные доменные сервисы, не микросервисы
    Shared DB
    Обычно единая БД для простоты
    User Interface
    Может быть монолитным или разделённым
    Event-Driven Architecture

    Асинхронная коммуникация через события:

    Broker Topology
    Без центрального координатора
    Mediator Topology
    Центральный event mediator
    Space-Based Architecture

    Для экстремальной масштабируемости:

    Processing Units
    Содержат логику и in-memory data grid
    Virtualized Middleware
    Messaging grid, data grid, processing grid
    Use Case
    Concert ticketing, online auctions
    Microservices Architecture

    Максимальная независимость сервисов:

    Bounded Context
    Каждый сервис = один bounded context
    Database per Service
    Изоляция данных, eventual consistency
    Choreography vs Orchestration
    Два подхода к координации
    Сравнение архитектурных стилей
    СтильDeployabilityScalabilitySimplicityCost
    Layered⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
    Service-Based⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
    Event-Driven⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
    Microservices⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

    Часть III: Soft Skills архитектора

    Architecture Decision Records (ADR)

    Документирование архитектурных решений:

    Title
    Краткое название решения
    Status
    Proposed, Accepted, Deprecated, Superseded
    Context
    Почему возникла необходимость в решении
    Decision
    Что решили и почему
    Consequences
    Плюсы и минусы выбранного подхода

    Architecture Fitness Functions

    Автоматическая проверка соответствия архитектуры:

    Cyclic Dependencies
    Проверка отсутствия циклических зависимостей
    Layer Violations
    Контроль нарушений слоёв (ArchUnit)
    Performance
    Автотесты на время отклика
    Security
    SAST/DAST проверки в CI/CD

    Ключевой инсайт: Архитектор — это не только технический специалист, но и лидер, переговорщик и коммуникатор. 50% успеха архитектора — это способность объяснить и «продать» своё решение стейкхолдерам.

    Применение к System Design Interview

    Что использовать на интервью

    • Architecture Characteristics: явно называйте выбранные характеристики и trade-offs
    • Архитектурные стили: обосновывайте выбор стиля (Event-Driven vs Service-Based)
    • Trade-off analysis: показывайте понимание компромиссов
    • ADR-подход: структурируйте объяснение как Context → Decision → Consequences

    Частые ошибки

    • Выбор микросервисов «по умолчанию» без обоснования
    • Игнорирование операционных характеристик (только функциональные требования)
    • Отсутствие явных trade-offs в решении
    • Over-engineering для простых задач

    Продолжение

    Building Evolutionary Architectures

    Следующая книга серии: Fitness Functions, Connascence и эволюция архитектуры

    Читать обзор

    Вердикт

    9/10
    Практичность
    8/10
    Глубина
    9/10
    Для интервью

    Fundamentals of Software Architecture — обязательная книга для тех, кто хочет понять роль архитектора комплексно. Особенно ценна классификация архитектурных стилей с чётким анализом trade-offs. Для System Design Interview книга даёт отличный фреймворк для структурирования ответов и обоснования решений. Рекомендуется после изучения базовых книг по System Design.

    Где найти книгу