Modularization of external configuration

[mirkosertic]

Moduliths is a great way for building Spring-based applications. It alows a well structured architecture style and even enforces it.

However, I have concerns about the external configuration in such an architecture. Let me elaborate the following scenario, which was quite common in projects I've seen in the past years:

Given any project, maybe in MVP state, based on the Moduliths style. Developers have multiple options to access external configuration. They can declare a single Spring bean with a @ConfigurationProperties an inject it into multiple modules. They can also declare a Spring bean per module. In both cases, they maybe use some style of naming convention to name the configuration values in their Spring Environment / .properties / .yaml etc files.

Now, the architecture starts to evolve. New modules arise, Modules are refactored or are deleted. Developers tend to refactor/reegineer only the code, but not the external configuration data. After a few development iterations, it is no longer clear which modules used which part of the external configuration. Maybe even the original naming convention is no longer coherent with the module naming at all. This makes it quite hard to estimate the impact of configuration changes.

The key point is here that the external configuration has no enforced structure. It is too easy to create a mess if you don't know about naming conventions or just ignore them.

For Moduliths, I'd like to see the following:

• External configuration usage at module documentation level

This should be easy to implement, as configuration is just a special case of Spring bean, and Moduliths already knowns the depenency graph. Bean introspection can then report the available options per bean. Of course this does not allow usage detection if single properties, only the whole bean would be covered. But this would be a good starting point. Maybe this documentation could also mirror the JavaDoc from the Spring bean, as property files of yaml is very restricted about inline documentation.

• Prevent duplicate usage of single configuration values

We can use Java type system to prevent modules accessing foreign configuration beans. The type system does not protect us from accessing foreign configuration data thru the Spring envionment, For Moduliths, maybe an Annotation Processor could check if two modules are using the same @ConfigurationProperties annotation with the same prefix.

• Enforcing of a clear and coherent naming convention between modules and external configuration

I'd like so see the ubiquitous language used in both module naming conventions and external configuration. This would make things a lot clearer for the development teams, QA and OPS to really know what a configuration setting does and what impact a change might have(with additional documentation, of course)

What do you think about this Idea?