"Modular monolith" has been a popular phrase in the PHP community recently with talks, podcast episodes and courses released on the topic.
The idea is that instead of all the code being in one namespace, like App, it's split into different modules such as for payments or a blog - whatever is relevant and appropriate for that application.
Each module contains its own classes and structure instead of everything being mixed together.
If you want to change something about payments, you go to the payments module and you don't need to worry about anything else.
What's interesting is that this is how I've always built Drupal applications.
Each includes Drupal core and any contributed modules installed via Composer, and a specific directory for application-specific custom modules.
These modules can be separate and standalone or they can interact and have dependencies and sub-modules.
Each has its own routes, services, tests and more, making them easy to organise and maintain compared to having all the custom code in one large monolithic namespace or module.
- Oliver
Was this interesting?
About me
I'm an Acquia-certified Drupal Triple Expert with 17 years of experience, an open-source software maintainer and Drupal core contributor, public speaker, live streamer, and host of the Beyond Blocks podcast.