Step 1: Define what architecture means by identifying the hard-to-change decisions the system must get right.
Step 2: Understand the problem space, actors, and system boundaries to avoid solving the wrong problem or allowing scope creep.
Step 3: Define core system capabilities in business terms, independent of features or technology.
Step 4: Identify core domain concepts (nouns) that represent what truly exists in the system.
Step 5: Assign clear responsibilities to each concept and define invariants that must always hold true.
Step 6: Describe happy-path system interactions and flows showing how concepts collaborate to achieve goals.
Step 7: Design for failure by identifying what can go wrong, who owns recovery, and how invariants are protected.
Step 8: Choose an architectural style and decompose the system into modules aligned with business capabilities.
Step 9: Define stable contracts (commands and events) that govern how modules interact without leaking internals.
Step 10: Map architectural decisions to implementation guidance while keeping technology choices flexible and reversible.