Meier Online

Sorry, this entry is only available in Deutsch.

ArchUnit is a tool which enables you to test whether Java code (or Kotlin code) adheres to certain architectural requirements. For example, given a Spring application you can check that does a  service class does not call a controller class.

Such a rule sounds superfluous, why should I call a controller from a service?

But when it happens, we get a cyclical dependency, and this makes an application harder to maintain. With ArchUnit, it is easy to check this in your test suite.

I have tried this check in a project I have worked for. ArchUnit did not found any violations. Not surprisingly, but reassuring.

You can also use ArchUnit to define layers by directories, and then check the dependencies between the layers. This can look like this:

layeredArchitecture()
.layer("Controller").definedBy("..controller...") 
.layer("Service").definedBy("..service.") 
.whereLayer("Controller").mayNotBeAccessedByAnyLayer()
.whereLayer("Service").mayOnlyBeAccessedByLayers

The test delivered me a surprise in our project: The service layer had some dependencies on the controller layer!
Most of these dependencies had to do with data transfer objects (DTOs). The DTOs have been defined in our project as part of the controller layer. However, in some cases in service methods assume DTOs as parameters, so the service got a dependency on the DTO defined in the controller layer.

This leads me to the not so trivial question: In which layer do the DTOs and their mappers belong? And in which layer does the transformation of the DTOs into the model objects happen? In the controller or in the service?

If we consider the DTO’s to be part of the controller layer, then the code of the service layer should not know anything about the DTOs. However, it also means that the controller must then know the model layer. You can argue that the top layer would access the lower layer, bypassing the middle layer, and this should not be.

On the other side, the DTO correspond to the JSON Objects that the controller receives. So it feels wrong to me to put them into the service layer.

Time to do some research, what is this DTO pattern, and where should I put the

I came across the blog of Mark Seeman, who asked the following question:

Is Layering Worth the Mapping?

His initial question is: Imagine I want to insert an additional field in my model and also in my database and show it also in the end in the user interface.

Then I have to change not only the model, but also DTO and mapper. For classic Java classes, getter and setter methods are added.
It would be much easier, more maintenance-friendly and also less error-prone to just use the entity classes everywhere.

I found these conclusions remarkable here:

1. If You get throw away the DTOs, your layers do not provide you any abstraction.
2. If your application essentially generates and edits data sets (CRUD operations), then you do not need strict layers for this. They only cause an artificial division of an actually simple task. The model is the right abstraction for the application.
3. But if Your application runs operations that go beyond pure update of a record, then it is often easier to see these operations as commands. These commands come with their own data defintion, as the CQRS pattern suggests. So instead of a large DTO with many fields, you better use many smaller command objects with comparatively few fields. And for the read operations, you need the DTO only to have a filter so you not return all fields.

So DTOs are probably much less useful than many developers think. Why are they used almost everywhere in the Java environment? I found an important note from Adam Bien: In earlier versions of the J2EE standard, DTOs were absolutely necessary. the reason was that normal entity beans were not serializable. Meanwhile, a generation of J2EE developers has grown up with this “best practice” and passed it to their younger colleagues.