Most of my posts around clean code until now have been focussed on around the object level of design. One thing that is often abandoned is the use of modules, I’m guilty of it too. I remember at my first job creating modules was a real pain and was always something I wanted to avoid as it’d cause weird generic errors in our system that you’d spend hours trying to fix. That was a bit of an edge case; creating a module most of the time is just a case of clicking a few buttons in your IDE.

I feel modules are generally underused unfortunately. The alternative is usually to create a directory inside the module and then dump all of the files in there. You get some organisation in terms of keeping the files close together but it’s still messier than a single project. You don’t get the benefits of cohesion either - small modules are easier to understand and to maintain.

One of my main gripes with dependency injection is that it usually ends up with everything being made public. Modules, like classes should encapsulate or hide the implementation details. If everything is public then the modules are likely to depend on pieces of code throughout the module making changing that module difficult in the future. Autofac (.NET) has a nice module system which allows you to register types in each module which lets you keep the types internal to the module as oppose to having to register everything in one big file in Main().

In the image below you have a module where everything is public being referenced - it usually degrades into a kind of free for all. Then you have a module that has explicitly been designed with a public API for other modules to interact with it. Which do you think is going to be easier to change in 6 months time?

Another point worth mentioning about modules is the direction of the dependency. Should your business logic depend on the database layer to fetch the data or be dependant on your API code? No way. The database is a plugin. The web API is a plugin. Any user interface you have is a plugin. The domain, the problem that you’re solving, shouldn’t care about any of this extra stuff because they’re just ‘details’ to the domain that it doesn’t care about.

Organising the dependencies in this way keeps things more straightforward to change later down the line. You might think we’re never going to change this database, but you never know. To be agile we need to design our system assuming things will change. Another reason for doing this is testability. While business logic depending on the database could be testable if written by a disciplined developer, a dependency in the other direction requires it to be testable.

How do we reverse the direction of a dependency? Dependency inversion of course! Here it is if you’ve forgotten:

By adding an interface, it’s possible to flip the direction of any set of dependencies - this is probably the most useful thing to do with an interface. Interfaces don’t have to be in the same module as the implementations of the interface; some codebases seem to have this unwritten rule for some reason. An interface is merely a description of a piece of behaviour - it doesn’t care how it is implemented and so the code that implements an interface doesn’t have to be located with that interface either. I use the diagram to below to remember which directions the dependencies should travel in:

The diagram above is a simplified version of a diagram in ‘Clean Architecture’. Infrastructure contains things like the database, your web API - the details. The application layer relates to logic specific to this application and/or acts as a service/gateway layer between the domain and infrastructure. Lastly, the centre of everything - the domain. The domain should be the most important part of the application. If I could only test one of those layers, the domain would be it.

I’m occasionally asked questions about ‘how do I unit test my application when I use this X database?’ or ‘with X framework?’. If something is a pain to unit test like a UI framework or a particular database then don’t unit test it. Write an integration test instead. By separating your code into the layers above you’re going to have a clear boundary between the code you are testing and the code you are not testing. For the code you’ve decided not to test: keep it as dumb as possible.