![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
When I was a child, I used to lie on the bed and gaze for a long time at the patterns on an old Soviet rug, seeing animals and fantastical figures within them. Now, I more often look at code, but similar images still emerge in my mind. Like on the rug, these images form repetitive patterns. They can be either pleasing or repulsive. Today, I want to tell you about one such unpleasant pattern that can be found in programming.
Imagine a service that processes a client registration request and sends an event about it to Kafka. In this article, I will give an example of an implementation that I consider an antipattern and suggest an improved version.
The Java code below shows the code of the RegistrationService
class, which processes the request and sends the event.
public class RegistrationService {
private final ClientRepository clientRepository;
private final KafkaTemplate<Object, Object> kafkaTemplate;
private final ObjectMapper objectMapper;
public void registerClient(RegistrationRequest request) {
var client = clientRepository.save(Client.builder()
.email(request.email())
.firstName(request.firstName())
.lastName(request.lastName())
.build());
sendEvent(client);
}
@SneakyThrows
private void sendEvent(Client client) {
var event = RegistrationEvent.builder()
.clientId(client.getId())
.email(client.getEmail())
.firstName(client.getFirstName())
.lastName(client.getLastName())
.build();
Message message = MessageBuilder
.withPayload(objectMapper.writeValueAsString(event))
.setHeader(KafkaHeaders.TOPIC, "topic-registration")
.setHeader(KafkaHeaders.KEY, client.getEmail())
.build();
kafkaTemplate.send(message).get();
}
@Builder
public record RegistrationEvent(int clientId, String email, String firstName, String lastName) {}
}
The structure of the code can be simplified as follows:
Here, you can see that the methods form an unbroken chain through which the data flow, like through a long, narrow intestine. The methods in the middle of this chain are responsible not only for the logic directly described in their body but also for the logic of the methods they call and their contracts (e.g., the need to handle specific errors). All methods preceding the invoked one inherit its entire complexity. For example, if kafkaTemplate.send
has a side effect of sending an event, then the calling sendEvent
method also acquires the same side effect. The sendEvent
method also becomes responsible for serialization, including handling its errors. Testing individual parts of the code becomes more challenging because there is no way to test each part in isolation without using mocks.
public class RegistrationService {
private final ClientRepository clientRepository;
private final KafkaTemplate<Object, Object> kafkaTemplate;
private final ObjectMapper objectMapper;
@SneakyThrows
public void registerClient(RegistrationController.RegistrationRequest request) {
var client = clientRepository.save(Client.builder()
.email(request.email())
.firstName(request.firstName())
.lastName(request.lastName())
.build());
Message<String> message = mapToEventMessage(client);
kafkaTemplate.send(message).get();
}
private Message<String> mapToEventMessage(Client client) throws JsonProcessingException {
var event = RegistrationEvent.builder()
.clientId(client.getId())
.email(client.getEmail())
.firstName(client.getFirstName())
.lastName(client.getLastName())
.build();
return MessageBuilder
.withPayload(objectMapper.writeValueAsString(event))
.setHeader(KafkaHeaders.TOPIC, "topic-registration")
.setHeader(KafkaHeaders.KEY, event.email)
.build();
}
@Builder
public record RegistrationEvent(int clientId, String email, String firstName, String lastName) {}
}
The diagram is shown below:
Here, you can see that the sendEvent
method is completely absent, and kafkaTemplate.send
is responsible for sending the message. The entire process of constructing the message for Kafka has been moved to a separate mapToEventMessage
method.
The mapToEventMessage
method has no side effects, and its responsibility boundaries are clearly defined. Exceptions related to serialization and message sending are part of the individual methods' contracts and can be handled separately.
The mapToEventMessage
method is a pure function. When a function is deterministic and has no side effects, we call it a "pure" function. Pure functions are:
I would suggest the following techniques that can help avoid such antipatterns in the code:
All these techniques are closely related and complement each other.
This is an approach to test coverage that emphasizes integration tests, which verify the service's contract as a whole. Unit tests are used for individual functions that are difficult or costly to test through integration tests. I have described tests with this approach in my articles: Writing Effective Integration Tests in Spring: Organized Testing Strategies for HTTP Request Mocking, Improving Integration Test Transparency, Reliable Testing with Kafka: Isolation Techniques.
This technique is described in Kent Beck's book "Tidy First?" The main idea is that reading and understanding code is harder than writing it. If the code is broken into too many small parts, it may be helpful to first combine it into a whole to see the overall structure and logic, and then break it down again into more understandable pieces.
In the context of this article, it is suggested not to break the code into methods until it ensures the fulfillment of the required contract.
This approach allows separating the efforts of writing code to implement the contract and designing the code. We don't try to create a good design and write code that meets the requirements simultaneously, instead, we separate these tasks.
The development process looks like this:
The article discusses an example of an antipattern that can lead to difficulties in maintaining and testing code. Approaches like Testing Trophy, One Pile, and Test-Driven Development allow you to structure your work in a way that prevents code from turning into an impenetrable labyrinth. By investing time in the proper organization of code, we lay the foundation for the long-term sustainability and ease of maintenance of our software products.
Thank you for your attention to the article, and good luck in your quest for writing simple code!