Most developers know the story where, as new features / releases / integration of new people into the team happen, the architecture and code drift further and further away.
Of course, you could have one or more experienced developers who look at the code once a week (or with PRs), identifying architecture issues and fixing them immediately.
But a safer way is to simply define the components in the code and the rules for these components that can be automatically tested, for example as part of your continuous integration build.
We’ll see how ArchUnit can help us test our architecture to contribute to the quality of our code, and also how to help new developers get familiar with these rules.
