Architecture Fundamentals and Design Principles
What this domain tests
This domain checks whether you can define architecture precisely and justify structural decisions. Expect questions on the ISO/IEC/IEEE 42010 definition (fundamental concepts or properties of a system in its environment, embodied in its elements, relationships, and principles of its design and evolution), on the boundary between architecture and detailed design, and on classic principles: separation of concerns, modularity, information hiding, abstraction, cohesion, and coupling.
Core rules
- Architecture decisions are the expensive-to-reverse ones. If a choice is cheap to change later, it is design, not architecture.
- Cohesion pulls related behaviour together; coupling pushes dependencies apart. Prefer high cohesion inside a module and loose, explicit, stable coupling between modules.
- Parnas' information hiding: modules should hide the decisions most likely to change, not merely hide data fields.
- The dependency rule in layered or hexagonal designs: source-code dependencies point inward, toward stable policy; infrastructure depends on the domain, never the reverse.
- Patterns are trade-off bundles, not badges. Layered suits teams needing clear separation; event-driven suits asynchronous, decoupled scaling but costs determinism and debuggability; microservices buy independent deployability with operational and consistency costs.
Worked example
A five-person team building a regulated claims system must choose between a modular monolith and microservices. Reasoning: independent deployability matters little at this team size; distributed transactions across claims and payments would add sagas and eventual consistency the business will not accept yet; operational maturity (observability, on-call) is thin. Decision: modular monolith with enforced module boundaries and separate schemas, so extraction stays possible. The principle is deferring irreversible cost while preserving optionality.
Traps
- Answering "microservices" reflexively; scenarios often reward the simpler structure that meets the quality attributes.
- Treating architecture as a document rather than a set of decisions and structures.
- Confusing encapsulation (a language mechanism) with information hiding (a design principle).
- Forgetting the environment: architecture is always a system in its environment.