Previously, I mentioned there were a couple of issues that I really wanted us to fix with our ACME registration service. In this section, we are going to use config injection to deal with two of them.

The first is the fact that many of our packages depend on the config and logging packages, and other than being a substantial single responsibility principle violation, this coupling is likely to cause circular dependency problems.

The second is our inability to test our calls to the exchange rate without actually calling the upstream service. So far, we have avoided adding any tests to this package for fear that our tests would then be affected (in terms of speed and stability) by that service.

First, let's examine where we are. Our dependency graph currently looks as shown in the following diagram:

As you can see, we have four packages (data, register, exchange, and main) depending on the config package and five (data, register, exchange, rest, and config) that rely on the logging package. What is perhaps worse is how these packages depend on the config and logging packages. Currently, they directly access public singletons. This means that when we want to test our logger usage or swap out some configuration during testing, we would have to monkey patch and this would cause a data race instability in the tests.

To address this, we are going to define one config for each of our objects. Each config will include the logger and any other configuration that it needs. Then, we replace any direct links to the global variables with references to the injected config.

This will result in a bit of shotgun surgery (a lot of little changes), but the code will be a lot better for it.

We will go through only one set of changes here; if you wish to see all of them, please review the source code for this chapter.