If you don't check your architecture it doesn't really exist.

If you don't check the architecture automatically, often the architecture is not followed due to the reason that the developer does not get a fast or even any feedback that some changes break the architecture.

The architecture is a contract between developers of a project on how to structure a software. In a classical architecture there are many layers (e.g. UI, business, persistence). The architecture defines which layer is allowed to talk to another layer.
To get such feedback fast we developed a tool called stereotype check.

How does the stereotype check help following the architecture contract?

In a layered architecture often there are some classes that implement a special behavior like transformer, controllers or business functions. They are called stereotypes. Stereotypes belong to a specific layer. Stereotypes are defined by a combination of:

Postfix of the classname
Package of the class
Interface implemented by the class
Class extended by the class
Annotations the class has

The stereotype check tests if a class conforms to a configured stereotype and checks if the class has a dependency to another stereotype class that is not allowed.

What is the need of stereotype check?

Fast feedback

The developer should get a fast feedback while implementing a new feature, if his code conforms to the architecture.

Many other tools check the code after the implementation is done. The check is done only by the build server (e.g. triggered by jenkins). Therefore the developer has to push the code to the project repository.
Many other tools that have an integration to an IDE, must be executed explicitly or have a long execution time.

As a checkstyle plugin the stereotype check is executed during the compilation of the code in the IDE. So the developer gets fast feedback. It can be also integrated in the build execution, so there is no need to rely on the IDE.

Many equal structured modules

In an application that has many modules with the same layer structure, there should be one central definition of the layers and not a copy of the definition in each modules.

Many other tools have the possibility to define a layered architecture, some of them with great graphical interfaces. But many of them have the problem that you can only define the layers for one module. For a second module you have to copy the layer definition and change e.g. the package names of the module.

With the stereotype check you can have one central configuration file for all modules. If there is the need to adapt the configuration module-specific, the module can define an override configuration file.