What Is Architecture: Top-Level Design, Modules, Components, and Three Principles

Architecture Is Top-Level Structure

Software architecture describes how a system is organized at a high level: what modules exist, how responsibilities are divided, how components communicate, and where the important boundaries are.

Architecture is not equal to technology selection. Frameworks, databases, and message queues are tools. Architecture is the reasoning that explains why those tools are placed where they are.

Modules, Components, and Boundaries

A module is a unit of responsibility. A component is a deployable or replaceable technical unit. A boundary defines what belongs together and what should communicate through contracts.

flowchart LR
    A["Business capability"] --> B["Module"]
    B --> C["Component"]
    C --> D["Interface"]
    D --> E["Runtime system"]

Three Practical Principles

The first principle is separation of concerns. Different responsibilities should not be tangled together.

The second principle is stable boundaries. Modules should communicate through clear contracts instead of relying on each other?s internal details.

The third principle is evolutionary design. Architecture should support change, because business understanding and technical constraints both evolve.

Architecture Is a Continuous Activity

Architecture is not only a document created at the beginning. It is continuously shaped by requirements, code, delivery feedback, and production constraints.

Best Practices

• Start from business capabilities, not fashionable technology.
• Make boundaries explicit and review them regularly.
• Keep contracts stable but allow implementations to evolve.
• Use diagrams to explain structure, then validate them against code.
• Treat architecture decisions as tradeoffs that need context.