Design and Development of Software Architecture
Domain 4: Design and development of software architecture
This domain tests how architectures are derived and evolved: decomposition, principles, patterns, interfaces, and iteration. The exam expects you to connect design choices to quality attributes and constraints, and to justify patterns by forces rather than fashion.
Core rules
- Decompose by cohesion and coupling; define boundaries around business capabilities or change reasons.
- Apply principles such as separation of concerns, information hiding, single responsibility, and dependency inversion.
- Choose architectural patterns by forces: layers for separation, pipes and filters for processing streams, event-driven for decoupling, microservices for independent deployment.
- Design interfaces for stability and replaceability; make dependency direction explicit and avoid cycles.
- Address cross-cutting concerns: security, logging, configuration, transactions, error handling.
- Evolve incrementally; use spikes and prototypes for uncertain quality risks; track technical debt.
Worked example
A small team builds a reporting feature inside a monolith. A candidate proposes microservices because of scalability. The architect examines forces: one team, shared database, low independent deployment need, but heavy report queries. The architect instead separates a reporting module with its own schema and asynchronous read model, preserving a modular monolith. Reasoning: this isolates query load and allows later extraction without paying distributed-system complexity now. The decision is recorded with a trigger for revisiting, such as independent scaling or team autonomy.
Traps
Pattern names without forces are weak. Premature microservices, cyclic dependencies, and chatty interfaces are common errors. Do not ignore non-functional requirements or operational cost. Do not treat architecture as a one-time phase; evolution and technical debt must be managed.