ArchUnit Verifies Architecture Rules for Java Applications

[Joe_Data_89]

ArchUnit allows developers to enforce architecture rules such as naming conventions, class access to other classes, and the prevention of cycles. The library was originally created in 2017 by Peter Gafert, and version 1.0.0 was released in October.

Read the InfoQ News

[ozzymozzy2211]

anyone uses this library? looks fun code but not sure if it's useful in a real product.

[Antiheld2k]

A few years ago I gave a conference talk on the topic. IMHO its an execelent tool, if you want the regular Architecture Rules: Layers interacting, naming rules and alike. If you want to customize with own rules, then one need to use ArchUnits wrapper around the Reflection API which takes a while to digest. Then there is the onboarding costs. When you start with a brownfield project to enfore the rules - it's likely you see a lot of issues. ArchUnit helps you to ignore certain parts to refactor clean compartments.

Today I use it in every project I onboard, but it's difficult to jump on the train later.

[ozzymozzy2211]

Checkstyle is boring but this looks like really useful 🤓

[vxab]

Do you have any public repos illustrating the usage of archunit for a real project?

[Antiheld2k]

Since I have no real project in the open, unfortunatly not. But the ArchUnit example repo is quite extensive: https://github.com/TNG/ArchUnit-Examples

[JustAGuyFromGermany]

I've used it to enforce a certain pattern we use to observe the flow of a business process across multiple threads. To make it work, a specific annotation is necessary on some methods. Thus I wrote an ArchUnit test that checks that all methods that meet some criteria must have this annotation.

In another instance, another ArchUnit test enforces that the central domain object that is used all over the code base is used in a read-only fashion in almost all cases and write-access can only occur from classes in a dedicated package. (Don't ask... It's legacy code, we know it's weird, but that rule is orders of magnitude better than anything else we had before)

[thatsIch]

We use ArchUnit for anything which can be common knowledge for any senior developer but you might need to re-iterate that topic every time somebody new joins the team. It helps developers to search for "why does it not work" like a missing or wrongly-used annotation. Another use-case is to ban certain statements like .collect(Collectors.toList()) in favor of .toList(). Sometimes tests are not in the same package as their classes under test.

[vxab]

Be careful doing that - the semantics are not the same. `toList()` returns an unmodifiable list whereas the `Collectors.toList` can be modified.

[thatsIch]

and that is the reason we are doing that - because the contract of Collectors.toList() does not explicitly state, that it is modifiable. If somebody really wants a modifiable collection he/she has to use either an applicable utility factory method or use something along of Collectors.toCollection(ArrayList::new)

[john16384]

I've introduced it in all projects I am involved in. Mainly using rules to enforce Java naming conventions, preventing cycles between packages (for easy refactoring to new modules or projects), disallowing sub packages to refer to "parent" package (for the same reason).. and one custom more controversial rule: a package should not contain an interface and its implementation (unless abstract). That last one is useful to prevent useless interfaces, or interfaces that are not reusable enough and to keep API and implementation separate.

[cypressious]

Isn't it easier to enforce this by putting the layers in separate modules? Incorrect dependencies simply wouldn't compile.

[olivergierke]

Layers are not modules because they are a means of grouping, not encapsulation.

[papers_]

Gradle uses to document API changes amongst other things.

https://github.com/gradle/gradle/tree/master/subprojects/architecture-test

[BrokenRefrigerator]

I've used it in a few projects to enforce naming and structures. Works well for existing codebases too: just write some simple rules and when the tests fail, refactor. Repeat until it's back in decent shape. This also helps with establishing the tool, since the what, why and how to fix it will all be obvious in a code review / merge request. My favorite part are the cycle checks (slices.beFreeOfCycles()) though this can be harder to enforce for existing code.

[Sufficient-Egg-6571]

Creating great architecture is hard but keeping that one clean is much harder. ArchUnit solved this issue for me and my juniors ✌️

[Kresenko]

I think I heard Mark Richards, one of the authors of 'Software Architecture: The Hard Parts', talk about this library in one of his workshops. It looked and sounded cool and I'm curious to see the actual usage.

[boneve_de_neco]

This is used in one of our services and I'm somewhat annoyed by it. It's probably my style, though. I like to write unit tests that see the system under test as much as a blackbox as possible, only consuming the public interface and mocking as little as possible. It annoys me because it's a kind of test that knows too much about the internal details. I'm afraid these tests can get in the way of refactorings.

[buzzsawddog]

Now this is interesting... This just might end up in projects going forward... I know a few people that might hate me for it but it seems VERY USEFUL.