Allow working with sub application-modules or "aggregates"

[lt-mayonesa]

Hey @odrotbohm et al, recently I had the opportunity of trying out spring-modulith on a service we built from scratch and I'm really liking it so far.

We did introduce a small change that I'm really curious to know what you think: instead of just register top-level modules I modified a bit the unit tests to recursively register each module as a top-level one, therefore enforcing the same dependency rules in any sub-module. The code looks something like:

  @Test
  void applicationModules() {
    registerPackage("my.root.package");
  }

  /**
   * When calling ApplicationModules.of() spring-modulith only registers top level modules. This
   * method recursively registers all sub-modules as if each was its own application module.
   *
   * @param javaPackage the package to register
   */
  private void registerPackage(String javaPackage) {
    var modules = ApplicationModules.of(javaPackage).verify();
    recurseApplicationModules(modules);
  }

  private void recurseApplicationModules(ApplicationModules modules) {
    modules.stream()
        .iterator()
        .forEachRemaining(
            applicationModule -> registerPackage(applicationModule.getBasePackage().getName()));
    new Documenter(modules).writeModulesAsPlantUml().writeIndividualModulesAsPlantUml();
  }

In my opinion this a nice tweak since it aligns better with the concept of domain aggregates, and it helps keep a more cohesive code base - if not in the long run services will probably just have some big top level modules where they bunch everything together.

This is how the structure ended up (it's a small project):

├── address
├── application
│   ├── alerting
│   └── sql
├── emballage
├── freightletter
│   ├── agreement
│   ├── emballageunits
│   ├── s3
│   └── transportdetails
├── security
└── supplier
    └── changes

WDYT? Would you consider this a correct approach?