Cross-module Communication

Question

Quite simply, it of course makes good sense to group parts of an application into appropriate modules.

Commonly, keeping these modules decoupled is not an issue, however it often arrises that data from the a user management module is required by other components.

It is substantially less than ideal by normal principles that these client modules would have knowledge of the user module's internal classes etc, which brings me to the question of how this cross-module communication is best architected.

My thoughts thus far are that a module could have a conventionally-named API class via which other modules could 'query' the module. This approach will still lead to a certain dependency, but at least only on the other module/its API.

Your thoughts on this would be greatly welcomed.

Thanks in advance, James

Answer 1

You might want to read up on "dependency injection". Symfony Components offers a solution for Dependency Injection and has lots of good reading/examples on the subject.

Answer 2

You could call the user module a "library". This terminology change can help clarify which modules are supposed to be top-level, and which ones manage lower-level activities that are intended to be used by multiple other modules. The CodeIgniter PHP framework uses this approach.

Answer 3

Well, "module" is extremely vague - exactly what defines a module can vary greatly from system to system.

I'm actually confused by exactly what type of scenario you're trying to avoid. It's not uncommon at all for two classes or groups of classes to communicate with eachother. That's why we have stuff like interfaces in the first place.

I guess in your scenario you could have a controller-like class (as in the C from MVC) in between your modules that would know the guts of each and could serve as a communication bridge.