Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Say, you have modules A through H. How/ where do you define dependencies for module A, considering it's supposed to exist in isolation ie. No use imports?
How does consumption of service/ dependencies work? I imagine there's some kind of entry point for them to get plugged in. Then each module pulls its dependencies from this entry point
I've taken a look at the nwidart modularization package, and my guess is that it's merely an arrangement construct, and not really an encapsulation strategy in the sense of the word
@nmeri17 Usually you setup bindings in a service provider of your app to resolve any abstracts to concretes, and only inject contracts/interfaces in your modules.
Checkout the docs on contextual bindings: https://laravel.com/docs/8.x/container#contextual-binding
I would also just read through everything on the container in general, and more on service providers and where to actually register them: https://laravel.com/docs/8.x/providers
Huh? I don't think you understand what I meant by modular architecture, let alone interaction between modules. However, I've gone through both links, and think they're one and the same thing. They just don't go hand in hand but can't exist without each other. There aren't features on the container that don't have one relationship or the other with the service provider
@nmeri17 And this is why I hate “modules”. Because in real world applications, it’s very rare a “module” can sit in complete isolation.
But, in the spirit of trying to answer the question, things like hexagonal architecture will use a concept of “ports” and “adapters” for communication. A message from Module B coming into Module A will enter module A through a port, and Module A will have an adapter to convert the message from Module B to a representation Module A can work with (usually adhering to an interface dictated by Module A).
However, given you’ve not given a specific example of your problem, I can’t really give you an specific example solution.
What you described is the same thing I said in my original question: port = entry point, adapter = concrete accessible to both publisher and consumer. That seems isolated enough to me, or do you have another definition of the term? I understand it to mean modules aren't tied to concretes i.e. you are free to swap in any implementation of your choice. It's isolated from a hard coded dependency.
I recently heard about an event based communication approach between the modules. This time around, no adapters, no ports. Interested consumers assemble at the listener and have full autonomy over how they want to react. What do you make of that?
@nmeri17 I’m not a fan of event-based architectures, because if you have events flying all over the place, and listeners in any number of locations, it becomes difficult to built up a mental map of how your application is structured and can make bugs difficult to find and reproduce.
I ABSOLUTELY agree. This was one of the pain points I identified with the pattern. In addition, events are one way. Which essentially means you can't pull data out of consuming services; you can't relay this data to the end user; you can't continue using it in same flow
Please or to participate in this conversation.