Software architecture basics

Architecture is the set of high-level decisions about how a system is divided into parts and how those parts relate. Good architecture has one overriding goal: make change cheap and local. Requirements always shift; the architecture that lets you adapt without rewriting everything is the one that wins.

Coupling and cohesion

Two words explain most of what "good structure" means:

• Cohesion (want it high): how related the things inside one module are. A highly cohesive module does one well-defined job — all its parts pull in the same direction.
• Coupling (want it low): how much one module depends on the internals of another. Low coupling means you can change one piece without breaking others.

The aim is high cohesion, low coupling: focused modules that interact through small, stable interfaces. When a tiny change forces edits across ten files, that's high coupling biting you.

Layering

A common way to achieve this is layers, each with a job, each depending only on the layer below:

• A presentation layer (UI / API) — talks to the outside world.
• A logic / domain layer — the actual rules of your system.
• A data layer — storage and retrieval.

The payoff is containment: swap the database without touching business rules; change the UI without rewriting logic. This echoes the systems-thinking idea of a pure core with effects pushed to the edges — the domain stays clean, the messy I/O lives at the boundaries.

Architecture is deferred decisions

The best architectures postpone hard-to-reverse choices. By hiding the database behind an interface, you delay committing to which database. By keeping logic independent of the UI, you avoid betting everything on one framework. Each good boundary is an option you keep open — which is why premature, over-specific structure (guessing wrong, early) is as harmful as none.

Where to go next

Systems rarely stand alone — they talk to others. Next: APIs and protocols, the contracts between systems.