Provide NamedInterfaces and shared modules lookup strategies

[murdos]

While trying to setup spring-modulith on an existing project that has already multiple modules, each one designed to used hexagonal architecture, I realized that spring-modulith does not support hexagonal architecture.

I think that by allowing spring-modulith modules detection to be more customizable, by providing additional extension points like strategies for identifying NamedInterfaces from a module base package, it should be possible to support this architecture, and others.

I made a rough experiment here:

• spring-modulith changes
• the hexagonal-project

Note that it would require to open API to create NamedInterfaces and NamedInterface.

Additionally, it would probably be useful to provide a lookup strategy to identify shared modules, when it's possible to automatically detect them, and avoid manual declarations through @Modulithic attribute.

[odrotbohm]

Thanks for opening up this ticket. I think before jumping to conclusions (Spring Modulith not supporting hexagonal architecture) and suggesting changes to the implementation, it would be helpful if you laid out what you're trying to achieve, what means you're using to implement those goals. We can then elaborate whether those are the appropriate ones or whether there are alternative approaches. Plus, you bring up three different things here: providing NamedInterfaces (already an internal abstraction), shared modules lookup strategies and support for Hexagonal Architecture (already support, although not a first-class citizen). I think we need to discuss and justify each of them individually.

Fundamentally, any of the separation of concerns architectures (Hexagonal, Onion) are an implementation detail to a module. With jMolecules, a library exists that allows declaring the architectural stereotypes language in the codebase. In combination with Spring Modulith's named interface concept, we know about several applications using Hexagonal Architecture and Spring Modulith in combination.

Is there any chance you provide a minimal reproducer to demonstrate what you're looking for? I cannot really tell that from the sample project you linked to. Ideally, without any references to third-party frameworks that might already come with precompile opinions? The last time I interacted with JHipster, the team was pretty opposed to a domain-oriented code arrangement approach, insisted on a rather technical first-level decomposition strategy, which is at odds with decomposition for encapsulation.

[odrotbohm]

Closing due to the lack of feedback. Feel free to reopen with further information.