What Do I Want To Achieve With The Architecture?
Future Proofing / Optionality
Times, requirements, technology changes constantly. If we are not able to catch up in a timely manner, we are putting the business under increasing risk. That's why it's important to make an effort and keep as many options open as possible for the future this is assuming we want to be in business long-term.
Modularity
I want to be able to deal and manage ever increasing complexity in an effective way. Breaking the system down into smaller self-contained parts is crucial for this purpose.
Separate concerns
I want to improve maintainability, scalability, and reusability by allowing me and others to focus on individual parts without affecting the entire system.
Independent Magic
When we write software, we usually want to solve a particular problem for our customers. This solution is what I call the "Magic". We want to keep this magic part as independent as possible from secondary concerns.
What Does It Look like?
The Three Parts
From a birds-eye view, I like to separate the software architecture into three main parts: entry points, the magic and supporting infrastructure.
Entry Points
This is the surface our users interact with, the application program interface (API) of our software.
The Magic
This is where the magic happens. This is our primary concern where we deal with solving the particular problems of our domain of interest. Here we don't want to deal with http, database particularities, etc. This where we want to implement inversion of control.
Supporting Infrastructure
This is the roads, the vehicles, the buildings that we need to run our business. In the world of software these are called databases, caches, queues, object storage, etc.
What Is The Folder Structure?
This is roughly what the folder structure might look like:
Model
|_ User
|_ Product
|_ ...
UseCase
|_ Register
|_ Login
|_ AddToCart
|_ ...
EntryPoint
|_ Http
| |_ Register
| |_ Login
| |_ AddToCart
| |_ ...
|_ Queue
|_ SendActivationEmail
|_ SendOrderSummary
|_ ...
Container
|_ Database
|_ Queue
|_ Cache
Summary
We call it domain-driven design, hexagonal architecture and so on which is great. Bottom line is, we want to support the business i.e. customers long-term and be able to respond to change in the most effective and nimble way possible. To achieve this we have to think about optionality, modularity, separations of concerns, cohesion, coupling and so on when designing the architecture of our systems.
