Provide a way to use a different module recognition strategy

[OLibutzki]

Today I tried to apply Moduliths (especially it's documentation facilities) to our package structure. Moduliths assumes that the modules are direct sub-packages of a base package. This assumption most often applies to our package structure, but there are some cases which do not fit that well.

1. Not all the sub-packages are modules. There are sub-packages which act as a library and I do not want this stuff to be treated as a module (in the sense of a domain module / bounded context).
2. Our modules have the following structure:
   • {modulepackage}.api – Public API of the module
   • {modulepackage}.impl – Internals which cannot be referenced from other modules

We can compose applications by adding impl-Modules to the runtime classpath which means that the module exists in an application if the {modulepackage}.impl is present at runtime. The existence of {modulepackage}.api is irrelevant if the corresponding impl-package is not available. Currently Moduliths identifies the module just because of the existence of {modulepackage}.api.

Generally speaking it would be great to have some kind of module recognition strategy which can be altered by a SPI. By default you could use a sub-package-based strategy, but I would like to implement a strategy which reflects our conventions how a module is structured and identified.

The idea is similar to the ArchitecturallyEvidentType concept which is used to provide different strategies how to identify Aggregate roots, entities or services.

[odrotbohm]

There's now a ModuleDetectionStrategy SPI whose implementations can be configured via META-INF/spring.factories. An implementation that only keeps the module base package if there's a nested impl package would look something like this:

class CustomModuleDetectionStrategy implements ModuleDetectionStrategy {

  private final ModuleDetectionStrategy delegate = ModuleDetectionStrategy.directSubPackage();

  /*
   * (non-Javadoc)
   * @see org.moduliths.model.ModuleDetectionStrategy#getModuleBasePackages(org.moduliths.model.JavaPackage)
   */
  @Override
  public Stream<JavaPackage> getModuleBasePackages(JavaPackage basePackage) {

    return delegate.getModuleBasePackages(basePackage).filter(it -> {
      return it.getDirectSubPackages().stream()
          .map(JavaPackage::getLocalName)
          .anyMatch("impl"::equals);
    });
  }
}

[OLibutzki]

Thanks, I will try it.

[OLibutzki]

Last deployed 1.1.0-SNAPSHOT at https://repo.spring.io/libs-snapshot/ is from 13-Nov-2020 16:25. Is this intended?

[odrotbohm]

The switch to main as primary development branch seems to have deactivated the publishing CI builds 🤦 . I've fixed that. Up to date snapshot available now.