Good question - quite a few actually. @ConditionalOnMissingBean on every public @Bean method, proxyBeanMethods = false on every @Configuration class, the thin wrapper pattern (auto-config classes must have empty bodies) - those are all structurally checkable. CAS doesn't use ArchUnit specifically, but the consistency you see in the codebase didn't happen by accident. The patterns that can't be easily enforced statically are the harder ones - like making sure every module contributes to shared capabilities through the configurer pattern instead of direct coupling. That's where code review discipline fills the gap.
That's fair - it does look odd in isolation. But the alternative is mixing "should this load?" conditional logic with "what should load?" bean definitions in the same class. When you're debugging why a feature didn't activate across 272 entry points, having one place to look at - just the annotations on an empty wrapper - beats scanning through 200 lines of bean definitions hunting for the one @Conditional that blocked everything. It's not magic, it's separation of concerns applied to auto-configuration. Looks weird, works well.
That's really the whole thesis. None of the patterns in the article are clever or novel - @ConditionalOnMissingBean has been in the Spring Boot docs since day one. What's hard is getting a team to apply it on every single bean, in every single module, for years, without anyone cutting corners. Discipline scales. Cleverness doesn't.
I've been a committer on Apereo CAS (https://github.com/apereo/cas) since the 3.0 days. It's an open-source SSO/identity platform - 400+ modules, Spring Boot 3.x, Java 21+. Deployed at thousands of universities, government agencies, and enterprises.
I wrote a book that walks through how the whole thing works internally - not configuration, but actual code paths. 30 chapters, 825 pages. The Spring Boot bootstrap sequence, the authentication pipeline, Webflow state machines, ticket registry internals, SAML2/OAuth2/OIDC protocol engines.
reply