Architecture Scales
There has been a lot of confusion over the years around the terms design and architecture. What is software design? What is software architecture? Where’s the line between the two — and does it even exist? Some developers say there is; others see no difference at all. Ultimately, it’s up to you how you interpret it. My goal here is simply to clarify the concepts for you😅.
Recognizing the different scales of architecture can help you make smarter decisions. That’s why it’s important to understand the distinctions between:
- design principles
- design patterns
- software design
- software architecture
- architecture patterns
- architectural styles
- software architecture
Each has its place — once you see how they relate, everything becomes much clearer 😉.
🎯 Design Principles
This is a bit out of scope of this article, but let's quickly mention design principles.
They help you make smarter decisions long before code becomes a tangled mess.
Design principles provide guidelines on how to write clean, maintainable, and scalable code
Examples:
- Divide and Conquer — split the problem into smaller parts, solve each part, and combine the results
- Separation of Concerns — divide a program into distinct sections, each addressing a separate concern
- SOLID — five principles that promote maintainable object-oriented design
- KISS (Keep It Simple, Stupid) — avoid unnecessary complexity
- DRY (Don’t Repeat Yourself)— reduce code duplication
- YAGNI (You Aren’t Gonna Need It)— don’t add features until they’re actually needed
🧱 Design Patterns
Every program has to start somewhere. Usually from spaghetti code😅. And don't lie to me. Everybody was there at some point.
Some parts of the code become unsupportable, so you have to structure those in a better way.
This is the point where developers start a journey to architecture and learn about design patterns.
Design patterns are well-known, proven solutions to common problems encountered in object-oriented design. They operate at the class or object level
Examples:
- singleton — ensures only one instance of a class exists
- observer — notifies multiple objects about state changes in another object
- decorator — adds new behavior to objects dynamically
- state — allows an object to alter its behavior when its internal state changes
- proxy — controls access to another object, adding a layer like lazy loading, access control, cache, or logging
- adapter —converts one interface to another expected by the client
- facade — provides a simplified interface to a complex subsystem
🧩 Software Design
Once you’ve established communication between certain classes, you may begin extracting code into a separate project.
Get iamprovidence’s stories in your inbox
Join Medium for free to get updates from this writer.
Often, the internal structure of these modules doesn’t follow a specific architecture — the main goal is simply to maintain low coupling and high cohesion.
However, that’s not always sufficient. Sometimes, the entire module must be deliberately designed in a particular way.
Software design (code architecture) refers to low-level structure of a single module
Examples:
- organizing a command-handler pattern inside the Application module to separate concerns
- using a rich domain model to enforce consistency and encapsulate business logic within the Domain project
- applying screaming architecture to make the component’s intent and purpose clearly reflected in its structure and naming
- designing a state machine to manage transitions in a workflow engine
- implementing the bridge pattern to enforce a common structure in reporting jobs
🧠 Architecture Patterns
One project is great. But do you know what is even better? Many projects😅.
Similar to what we had before, we need to organize and structure those modules somehow.
Architecture patterns provide guidance on how to organize many projects within a single application
Examples:
- MVC/MVP/MVVM — divides an application into Model, View, and Controller layers to separate business logic, user interface, and control logic
- Monolith Architecture — a traditional architectural style where the entire application is built, deployed, and run as a single, unified unit
- N-layered — divides the application into multiple layers with distinct responsibilities
- DDD Layers — focuses on aligning software design with the business domain
- Hexagonal Architecture (Ports and Adapters) — isolates business logic from external dependencies
- Onion Architecture — enforces dependency flow toward the domain
- Vertical Slice Architecture — structures the system around features or use cases, keeping all related layers (UI, Domain, Infrastructure) within a single, independent slice
- Multitenant Architecture — an architectural approach that enables a single instance of software to serve multiple independent user groups (tenants)
- CQRS — separates read and write models for scalability and clarity
- Event Sourcing — stores state as a sequence of events rather than a single snapshot
🗺️ Architectural Styles
One application is great. But do you know what is even better? 😂 Many applications.
Systems grow. Now they consist of multiple applications, and they all need to interact with each other.
Architectural styles define the overall structure and interaction of multiple applications
Examples:
- Client-Server — separates consumers (clients) from providers (servers)
- Modular Monolith — organizes the system into well-defined, independently developed modules within a single deployable unit
- Microservices — compose the system of small, independent services
- REST — defines a resource-oriented interaction style over a uniform interface
- Event-Driven Architecture — components interact through events rather than direct calls
- Serverless — abstracts server management by running functions or services on demand in a cloud environment
🏛️ Software Architecture
For the final, we have software architecture. It dictates the shape of the entire system.
It is also the most ambiguous term — often used to refer to any of the concepts above, depending on the scale you’re working at.
After all, architecture can be described in ways that apply across different contexts.
Software architecture describe components of a system and the relation between them
What’s fascinating is how very basic design patterns reappear at higher levels of abstraction, seamlessly blending into architectural styles 😅:
- a distributed cache acts like a singleton inside a cluster
- a facade pattern morphs into a gateway
- an anti-corruption layer is nothing more than the adapter
- the mediator becomes an event bus, while the observer is similar to queue (you can also argue that the observer is the webhook approach)
- concepts like saga represent state machines
I could go on — proxies, decorators, sidecars — but you get the idea. The concept remains the same; only the scale changes. That’s why mastering the fundamentals is so essential — it helps you recognize familiar patterns, no matter how big the system gets 🙃.
This recursive nature of software concepts — repeating at different levels of scale — is what makes architecture both challenging and beautiful 😌.
Summary
Let me quickly sum it up for you, so can easily compare those terms without scrolling 😁:
- Design Principles provide guidelines on how to write clean code
- Design Patterns address common, low-level problems within classes
- Software Design focuses on the internal structure of one module
- Architecture Patterns guide the organization of multiple modules in an application
- Architectural Styles describe the interaction between many applications
- Software Architecture shapes the whole system layout
👏 Give this article a clap if you liked it
☕️ You can also support me using the link below
✅ Follow to see more
🙃 And keep coding
