Structuring an application.
WHAT ARCHITECTURE DECIDES
Where code lives What depends on what Where state is held How data flows What is shared and what is not
WHY IT MATTERS
Applications without it become difficult to change, and changes have unpredictable effects.
WHAT TO ORGANISE BY
Feature, rather than by file type.
WHY
Files that change together should sit together.
WHAT LAYERS TO SEPARATE
Presentation Application logic Data access
WHY
Each can then be changed and tested independently.
WHAT TO ESTABLISH
Which direction dependencies flow.
WHAT THE RULE SHOULD BE
Features may depend on shared code. Shared code may not depend on features.
WHY
Otherwise everything depends on everything.
WHAT TO PUT IN SHARED CODE
Genuinely reusable components and utilities Design system elements Cross-cutting concerns
WHAT NOT TO PUT THERE
Anything used once.
WHAT TO DOCUMENT
The structure and its rules, for whoever arrives later.
WHAT TO ENFORCE
Those rules, with tooling where possible.
