Base
Fundamentals of Software Architecture
A systematic introduction to architectural characteristics and styles.
Software architecture is a set of key decisions about the structure of the system, module boundaries, interactions, and non-functional requirements. These are the decisions that are most difficult to change later and that determine the quality, speed of change and cost of support.
What is software architecture
- System structure: components, boundaries, dependencies.
- Non-functional characteristics: latency, reliability, security, cost.
- Operating model: deployment, monitoring, evolution.
- Architectural solutions and their justification (ADR, trade-offs).
Why modeling notations matter
UML, C4, ArchiMate and BPMN provide a common language for architecture and design discussions. They align understanding between engineers, product and business, and help capture system trade-offs and evolution over time.
Common command language
Notations help to talk about architecture accurately and without unnecessary interpretations.
Fixing decisions
Diagrams preserve context and design decisions so the team doesn't lose track of their ideas.
Understanding the Tradeoffs
Models show the boundaries, dependencies and weaknesses of the system.
Accelerate discussions
A one-page diagram often replaces an hour of oral explanations.
Practical chapters on notations: UML, C4 Model, ArchiMate, BPMN.
Why think about architecture in System Design
Quality and risks
The architecture sets the SLA, stability, security and limits of the system.
Rate of change
Boundaries and interfaces allow you to develop the product without constant rework.
Cost of ownership
The right trade-offs help control infrastructure and operating costs.
Why are these books in this part
This part is assembled as an “architectural framework”: from requirements and quality characteristics to evolution and modularity. All books complement each other and answer the architect’s key questions: what are we building, how will we arrange it, how will we change it.
About requirements, prioritization and change management.
Architectural characteristics and basic styles.
Decomposition of a monolith, data ownership, orchestration vs choreography.
Trade-offs, ATAM, a practical approach to architecture.
Evolution of the system and fitness functions.
Architecture as a process and product approach.
Reducing complexity through modules and APIs.
Boundaries, dependencies, SOLID principles.
Design systems, processes and scalable frontend.
How to read the section
- Start with requirements and architectural characteristics.
- Move to complex solutions and decomposition.
- Fix the material on the evolution and purity of architecture.
If you need practice support, start with architectural solutions at scale And evolutionary architecture in practice.