What Is Software Architecture?
By the end of this lesson
Explain what architecture governs, and why it is a set of trade-offs rather than a set of rules.
Architecture is the set of structural decisions that are expensive to change later.
That definition is more useful than it sounds, because it tells you what counts. Which variable name you choose is not architecture — you can rename it this afternoon. Whether your business rules can run without a database is architecture, because changing that answer later means touching everything.
Decisions that usually qualify:
- How the system is divided into parts, and where the boundaries fall
- Which direction dependencies point
- How parts communicate — direct calls, HTTP, messages
- Where state lives and who is allowed to change it
- What the system does when a dependency is unavailable
- Which qualities you are deliberately protecting: testability, throughput, simplicity
Architecture is trade-offs, not a checklist
Most architecture material presents patterns as improvements: layer your application, add a repository, split into services. Each of those has a cost, and if you do not have the problem it solves, you have paid the cost for nothing.
Splitting one application into eight services buys independent deployment. It also buys network calls between things that used to be method calls, distributed failure modes, eight deployment pipelines, and debugging that spans several processes. For a large team with genuinely independent areas, that can be worth it. For three developers building one product, it is usually a serious mistake.
The diagram shows the one principle that pays off at almost any scale: dependencies point inwards, toward your business rules, never outwards toward infrastructure.
The practical consequence is that your core logic does not reference your database, your web framework, or any external service. It can be tested by calling it — no database, no HTTP, no waiting. That single property is worth more than most of the patterns that get more attention.
What the dependency direction actually buys you:
| Logic depends on infrastructure | Infrastructure depends on logic | |
|---|---|---|
| Testing a business rule | Needs a database running | Call a method |
| Test speed | Seconds per test | Milliseconds |
| Changing database | Touches business logic | Touches one adapter |
| Reading the rules | Mixed with queries and mapping | Stated on their own |
Summary
- Architecture is the decisions that are expensive to reverse
- Every pattern has a cost; adopt one only when you can name the problem it solves
- Dependencies pointing inwards is the principle that pays off at nearly any scale
- Match the amount of architecture to the lifespan and risk of what you are building
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Think about it
A team of three is building an internal tool for around fifty users. Someone proposes splitting it into six microservices for scalability. What would you ask them?
Show solution
What scaling problem are we currently experiencing? Fifty users does not typically require distribution — one modest application handles that comfortably.
Who deploys independently? The main benefit of separate services is independent deployment by separate teams. With three people there are no independent teams.
What is the cost? Six pipelines, six sets of configuration, network calls between services, distributed debugging, and partial-failure handling — carried by three people.
A reasonable alternative: one well-structured application with clear internal module boundaries. If a genuine scaling or team-boundary need appears later, those boundaries are where you would split it.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.