Your Brain on Inversion of Control and Dependency Injection

I will now wrap up my discussion with a look into Hexagonal/Ports and Adapters architecture and the use of DI. To do so, it’s helpful to understand the Dependency Inversion Principle (DIP). I’m going to keep this brief, so please don’t get hung up on my summary of DIP and a simple but useful example.

Using the Layers architecture example from Eric Evans’ blue book, which I also use in Chapter 4 of my red book, these are the common layers from top to bottom:

• User Interface
• Application
• Domain Model
• Infrastructure

All lower-level layers are restricted from depending on higher-level layers. This causes a problem when an interface defined in a higher-level layer needs to be implemented in a lower-level layer such as the infrastructure. Yes, you can implement the interface in the same layer as the interface is defined, but then why use layers at all if concerns can’t be consistently separated? And anyway, do you really want technology in your domain model? Answer: No. No, you do not.

The solution to this conundrum comes from the use of DIP. In essence, DIP says to make higher-level layers depend on interfaces defined in lower-level layers. This is one example of how inversion takes place.

(Note: Of course DIP is more elaborately defined in full. By some definitions it sounds like DIP requires an entirely different place (module, al la package or namespace) to house interfaces that are to be depended on by any layer. For the sake of brevity and to maintain focus on how to deal with typical challenges with the Layers architecture, I won’t describe Ports and Adapters here in those terms.)

Using the principles of Dependency Inversion, the Infrastructure is moved to the top, inverting the direction of interface dependencies that must be implemented there:

• Infrastructure
• User Interface
• Application
• Domain Model: interfaces for Repositories

Given that the Repository tactical pattern always requires a technical implementation for production use, the Infrastructure layer will now depend downward on the Domain Model for Repository interfaces. Doing so adheres to the proper use of Layers. Here’s an example of a Repository that is implemented in the Infrastructure layer, with its interface defined in the Domain Model layer:

// Infrastructure: DataSource

package matching.infrastructure.persistence;

public interface DataSource {
  . . .
}

public class PooledPostgresDataSource implements DataSource {
  . . .
}

// Infrastructure: PostgresProposalRepository

package matching.infrastructure.persistence;

import matching.model.proposal.ProposalRepository;

public class PostgresProposalRepository implements ProposalRepository {
  private DataSource dataSource;

  public PostgresProposalRepository(DataSource dataSource) {
    this.dataSource = dataSource;
  }
  . . .
}

// Domain Model
package matching.model.proposal;

public interface ProposalRepository {
  . . .
}

The PostgresProposalRepository constructor requires a DataSource. In this case constructor injection is used to give the PostgresProposalRepository its PooledPostgresDataSource.

Now, consider the Application layer that requires the use of the PostgresProposalRepository:

// Application
package matching.application.proposal;

import matching.model.proposal.ProposalRepository;

public class ProposalCommands {
  private ProposalRepository repository;

  public ProposalCommands(ProposalRepository repository) {
    this.repository = repository;
  }
  . . .
}

Finally, here’s an example of a service bootstrap initializing the DataSource, PostgresProposalRepository, and the ProposalCommands instances. The bootstrap is the main(), which instantiates the Matching service and initializes it:

 public class MatchingService {
  private DataSource dataSource;
  private ProposalCommands proposalCommands;
  private ProposalRepository proposalRepository;

  public static void main(String args[]) {
    var matchingService = new MatchingService();
    matchingService.initialize();
    . . .
  }
  . . .
  void initialize() {
    this.dataSource = new PooledPostgresDataSource(new DataSourceConfiguration());
    this.proposalRepository = new ProposalRepository(this.dataSource);
    this.proposalCommands = new ProposalCommands(this.proposalRepository);
    . . .
  }
}

Some may wonder how mocks can be used to test the MatchingService’s method initialize(). After all, there are no parameters to make test mocking possible. The answer is, mocks are purposely not used. It’s extremely important that the fully expected and real production objects are initialized properly. To do so, an integration test is used to test initialize() rather than a mocked unit test. Use Testcontainers for this and all real mechanism tests, including PooledPostgresDataSource and PostgresProposalRepository, which both must be tested against their respective technical mechanisms. The bootstrap is run only in production and any UAT and thus need not be mocked for tests that directly depend on it (there won’t be any) and that must be fast. There can be literally one test for the bootstrap and it can be run infrequently if it is very slow, which it will likely not be, given the use of Testcontainers.

There you have it, Dependency Injection using constructor injection at it’s finest; the finest being the simplest. A typical DDD strategic modeling Bounded Context will tend to be smallish. In this case there are only a few Aggregate types in the Matching Context. The entire start up is just a few more initializations away from service ready to roll.

Seriously, why do you need an Inversion of Control Container?