user-icon Volker Koch
17. October 2017
timer-icon 3 min

Architecture validation: ArchUnit vs. stereotype check

Recently a colleague asked me if I know ArchUnit as architecture validation tool und how does it compare to our stereotype check. Here is what I think about it. Please have a look at the project sites for detailed informations.

Compare the approaches

ArchUnit has the same goal as stereotype check, but a different approach: Giving the developer fast feedback, if her/his work conforms to the architecture. Using ArchUnit you have to implement a UnitTest that checks all your classes against a ruleset implemented in Java. Using stereotype check you have to configure a checkstyle plugin with a xml file. The benefit of the checkstyle approach is that the feedback is given directly while typing. The unit test approach might find architecture problems at the end your development, when you execute all unit tests before you commit your changes. To solve these problems you might have to refactor your whole change. But getting feedback before committing the changes, is better than after commit. Empirically a architecture problem that is committed, will stay in the code base for a long time.

Both approaches support a central definition of the checks, which can be modified by a project specific check definition. A architecture team can provide a standard check definition, which can be extended by the team implementing a part of the application.

But ArchUnit has some clear benefits. ArchUnit uses java to implement the checks instead of xml. For java developers this is much more easier and writing unit tests is what java developers should do every day. Using stereotype check you are restricted to checks defined by its xsd. In java you can add additional checks easily.

Because ArchUnit checks are implemented against the bytecode, checks can be implemented for classes which are not in the source path. Stereotype check as checkstyle plugin only sees the source code of one class. This can be a problem, when your check needs information about another class which is not in your source path.

Compare some checks

To compare the different approaches in detail I implemented some checks with ArchUnit for a project in that I currently use stereotype check to see if the same checks can be implemented.

Check dependencies between classes by package

In stereotype check you have to define 2 stereotypes and a dependency to allow the use. All others disallowed

The same in ArchUnit

Check dependencies between classes by postfix

Class with a postfix must be in specific package

Class with a postfix should be in a package and has a annotation

Class with a postfix should inherit from a base class


The answer to the question of my colleague is that it depends on your needs and preferences. But the information above may help you to decide.

Comment article