Architecture
In order for big projects to stay maintainable and scalable, it is crucial to isolate specific
responsibilities into separate layers. That way, each part can be managed and updated
independently without causing cascading effects throughout the entire application.
The task of each layer is clearly defined, what it needs as parameters and what it returns.
There are multiple ways to structure a system, and every article on the internet seems to describe layers with similar names in totally different ways.
The slim-example-project, slim-api-starter and slim-starter, use three main layers inspired by the Domain Driven Design (DDD): Application, Domain and Infrastructure.
The Application layer is the top-most layer and contains the code that is responsible
to deal with everything going out to the client or coming into the application after
the front-controller.
It contains middlewares,
handles HTTP requests (Action),
handles errors and returns the HTTP response.
The Application layer is responsible for orchestrating the execution of business operations, delegating the actual business logic to the Domain layer.
The Domain
layer is the heart of the application encapsulating the core business logic
and rules.
Essential concepts and behaviours for the application to run as desired are defined here.
It contains the service classes, DTOs, value objects, exceptions and is responsible for the
interaction with the infrastructure layer.
The Infrastructure layer is the bottom-most layer and is responsible for the communication
with external dependencies such as the database via repositories, the file system, and the mail server.
It needs to be separated from the domain layer to increase testability and facilitate
the replacement of adapters to external dependencies with other implementations.
This layer should not contain logic and not be aware of the domain layer (but
may create
and return DTOs from the Domain).
The classic approach would be to have three main folders inside the project directory src
to clearly separate the layers Application, Domain and Infrastructure.
Everything Domain-related
would be in the Domain folder, and the repositories for each module / feature would be in the
Infrastructure parent folder.
Example directory structure:
├── Domain
│ ├── Module 1 # (e.g. Authentication)
│ │ ├── Service
│ ├── Module 2 # (e.g. Client)
│ │ ├── Service
│ └── etc.
├── Infrastructure
│ ├── Module 1 # Authentication
│ │ ├── Repository
│ ├── Module 2 # Client
│ │ ├── Repository
│ └── etc.
Having the layers separated first and then the modules in each layer makes it unnecessarily more difficult to maintain and keep an overview, especially for projects that have lots of folders and modules.
If a new feature or module is added or changed, the developer has to jump between
the Domain and Infrastructure folders to make the changes.
Scrolling between those different "layer-folders" and searching the right module folders in each layer
is not efficient in the practical world.
There is a clean solution to this, and it's called the vertical slice architecture.
Instead of separating the layers first and then the module folders in each layer,
the vertical slice architecture suggests having the module folders in the same parent folder
(for example, "Domain") and separate the layers inside each module folder.
Every module is now a "Slice" containing all the layers by itself.
To have an even more concise and less cluttered codebase, the "Infrastructure" keyword can be
eliminated as long as the devs are aware that its components (e.g. "Repository") inherently belong
to a different layer than the Domain components (e.g. "Service").
The directory structure of before would look like this now:
├── Domain
│ ├── Module 1 # Slice
│ │ ├── Service # Domain layer
│ │ ├── Repository # Infrastructure layer
│ ├── Module 2
│ │ ├── Service # Domain
│ │ ├── Repository # Infrastructure
│ └── etc.
Components of the Application layer such as Actions could also be present in each of the slices,
but I have made the design choice to keep this whole layer separate in its own
src/Application folder.
This is to distinguish the components of that layer very clearly.
The Directory-Structure contains an overview of the folder structure.
