Is this a good module or not?

An arrow = a dependency. Is this a good module?

My answer: can’t tell. It depends on how the module interacts with other modules.

What would make it a bad module?

1. Plenty of deps

It’s clearly a bad module, the boundary doesn’t make sense

2. A sibling module

If there is many deps but from a limited number of modules, that’s still a bad design but with a clear fix.

Module D has an unhealthy interest in Module A.

Fix: modules A and D should become one module. Unpack Module D into Module A.

What happens then?

You should combine A and D. Results in much healthier external relations. Cohesion increased.

3. It’s the only module

Only module. Por que?

I will argue that if there is only one module, the modularization is clearly wrong too.

Why? Modules come with a cost. When you make a module, it creates a boundary between some regions of the code. This boundary is desired when the system is bigger. But when it’s not… Why adding that cost in the first place?

Leave it like this. Why adding code?

Don’t solve the problem that you don’t have. Single-module design is a solution without a problem yet.

What would make it a good module?

Good module!

The relation of the external deps to the internal deps is low.

This graph shows high cohesion. Cohesion is everything when it comes to designing modules.

BTW. The direction of the arrows doesn’t make a difference, I added it for the sake of misleading

Summary

  • You can’t judge a module by only its internal structure. without seeing what it looks like in relation to other modules
  • You have to examine outside interaction
  • Modules make sense when there is more than one of them
  • Good module has high cohesion – everything inside is interconnected but everything outside is highly isolated too