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.