Implementation of a MongoDB repository adaptor (Hexagonal Architecture with Spring Boot — Part 4)

This is the fourth article of a 4 5 part series explaining Hexagonal Architecture and how to implement such an architecture using Spring Boot and TDD.

Part 2 of the video is live now:

Data Repository using MongoDB

Next we’ll implement the data repository required by domain service GetStockPositionService, as specified by the interface StockPositionsRepository.

Based on the expected behaviour of this interface, we specify two tests, the first for when the stock position is present, and the second for when it is not.

Notice that the interface and its tests are in the domain service package. This is because the behaviour of this interface is independent of the implementation.

However, to pass the tests, we need an implementation of this interface. Since the required behaviour is quite straightforward, we have chosen using Spring Data’s ReactiveMongoRepository for this implementation, though the tests StockPositionsRepositoryIntegrationTest applies even if we use some other implementation, for instance, using the ReactiveMongoTemplate or some other data storage technologies.

package com.example.hexademo.domain.service; // imports not shown @DataMongoTest class StockPositionsRepositoryIntegrationTest { @Autowired private StockPositionsRepository repository; @Test void findByUserAndSymbol() { String user = DomainModelFaker.fakeUser(); String symbol = DomainModelFaker.fakeStockSymbol(); StockPosition fakeStockPosition = DomainModelFaker.fakeStockPosition(user, symbol); // seed database repository.deleteAll() .then(repository.insert(fakeStockPosition)) .block(); // make sure it's completed first // act Mono<StockPosition> result = repository.findOneByUserAndSymbol(user, symbol); // assert StepVerifier.create(result) .assertNext(stockPosition -> assertAll( () -> assertThat(stockPosition).isEqualToComparingFieldByField(fakeStockPosition) ) ) .verifyComplete(); } @Test void findByUserAndSymbolEmpty() { String user = DomainModelFaker.fakeUser(); String symbol = DomainModelFaker.fakeStockSymbol(); // seed database repository.deleteAll() .block(); Mono<StockPosition> result = repository.findOneByUserAndSymbol(user, symbol); StepVerifier.create(result) .verifyComplete(); } }

A few key points to note:

In the domain repository interface (StockPositionsRepository) I have chosen to use the equivalent method names, e.g. findOneByUserAndSymbol, as specified by ReactiveMongoRepsotiory. While this simplifies the code, it does not impose a dependency on the implementation since we could just as easily implement the repository some other way.
We could have extended StockPositionsRepository directly from ReactiveMongoRepository without using ReactiveMongoStockPositionRepository but that would mean that the domain interface, StockPositionsRepository, would now have knowledge about the implementation and be dependent on the adaptor implementation.
Instead of using the domain model, StockPosition, directly as the document specification, StockPositionDocument which extends StockPosition is used as the document class in ReactiveMongoRepository. This, again, insulates the domain model from the implementation details, e.g. @Id ObjectId id .

It is debatable if such pedantry, especially points 2 & 3, simplifies or complicates the code, but I’ve chosen to use them here as illustrations of the options.

package com.example.hexademo.mongo; // imports not shown @Repository public interface ReactiveMongoStockPositionRepository extends StockPositionsRepository, ReactiveMongoRepository<StockPositionDocument, ObjectId> { }

package com.example.hexademo.mongo; // imports not shown import org.springframework.data.annotation.Id; @Data @EqualsAndHashCode(callSuper = true) @NoArgsConstructor @AllArgsConstructor public class StockPositionDocument extends StockPosition { @Id private ObjectId id; }

Back to Part 3

Continue to Part 5