Another brain dump.
Updated: Dec 2, 2022, to reflect DataObjects (instead of DTO) and add Responses to enforce structure being returned. Removed Actions in favour of moving shared code to a Library
Discovered Laravel Actions brings the developer experience I like, making coding more fun and easier to reason about.
I thought about taking it a step further and seeing if there is a way to continue this simplicity for the rest of the application structure.
Here is what I came up with
Processes – Business Logic
Libraries – Collection of classes that encapsulates a rich set of functionalities – generally meant to be reused across processes, e.g.
Models – as you know them – interacts with the data store
DataObjects – as the name suggests – medium by which data is passed around throughout the applications (generally parameters or responses)
Responses – transforming data into a structure before being returned to the requestor
Services – Collection of classes used to interact with third-party interfaces. Services should be implemented using Contracts to enforce a standard interface. This will be helpful if you need to replace the service with another service.
That’s it nothing else to add or take away
Looks something like this:
app |--Processes |--DataObjects |--Libraries |--Models |--Responses |--Services |--Contracts
— OR —
app |-- Domain |--Foo |--Processes |--DataObjects |--Libraries |--Models |--Responses |--Services |-- Contracts |--Bar |--Processes |--DataObjects |--Libraries |--Models |--Responses |--Services |-- Contracts
The goal is to make your code easy to reason about, as there is a common understanding when moving from organisation to organisation.