How to be a better software developer? Part 3

Create modules with a maximum of one external dependency.

Here an external dependency is something that you cannot fully control. Examples:

• A service that is developed by another team and your team's application uses the service over a network.
• A tool, database for instance.

When your module has no external dependencies, it is a pure domain business logic module. When your module has an external dependency, it is an adapter that customizes the usage of the external dependency for the particular needs of your application. A module with an external dependency often lifts the abstraction level of the dependency a bit and it should be as small as possible with no business logic in it, implementing only the needed subset of the features that the dependency provides.

Why should you create modules that are either business logic modules or dependency usage modules? Some of the older but still valid reasons are:

• You can unit test your most important code, the business logic, so that you can easily fake the external dependencies and thus create faster and more reliable automated tests.
• You can reuse code across different applications. If you've once created an adapter for, say RabbitMQ, you can reuse that adapter in another application later if the usage is similar enough.

With the increased usage of microservice architectures and cloud services, there is also a newer benefit from this approach: it's easier to delete code that is no longer needed. Business logic doesn't usually get outdated unless your business changes drastically, but code for using an external dependency gets outdated more often than it used to in the past.

Oftentimes you no longer need to purchase expensive upfront licenses but you use cloud services that are charged according to usage. When you decide to change a tool, it no longer means that you've wasted an investment but rather that you get immediate cost savings or some other benefits from the change. Your application architecture is good when this change is as easy as possible.

Say for example that your team decides to move from AWS DynamoDB to Azure CosmosDB because Microsoft lowered prices in Azure. In the ideal case the code changes that you need to make consist of two steps:

1. Delete all the code files that deal with DynamoDB.
2. Implement the same interface that the DynamoDB implementation used to implement again with CosmosDB dependent code.

You don't need to worry if you break your most valuable code, the business logic, when you introduce this change if you manage to keep business logic separated from all the tool code.