Programmatic control of named interfaces

[ghferrari]

I was interested to see support for more programmatic control of modules in the recent 1.3 GA release. I was wondering if it is already possible to do something similar with Named Interfaces i.e. allow them to be customised programmatically; or if not, whether this could be requested as a new feature.

Here's the general use case I have in mind. Suppose you want to use a maven/gradle submodule within a Modulith module and you want it to have no Spring dependencies. For example, my particular use case is that I'd like the core of my Modulith modules to use hexagonal architecture, so I want to be able to define and build my core domain entities and use cases without any reference to Spring but then include them within a Modulith module. Since my core code must be defined without reference to Spring, I cannot use the usual NamedInterface annotation within that core. However, when the core is included in a Modulith module, I want to be able to instruct the parent Modulith module how to treat it - in particular, I want to be able to expose the ports of my hexagonal core as a NamedInterface because they represent its public API. So I'd still like to be able to specify that part of this core should be a NamedInterface, even though I don't want to do that by including a Spring annotation within the code for the core itself. (My use case is hexagonal architecture, but others may have other use cases that would also benefit from programmatic control of Named Interfaces).

When I reflected on this request a bit more deeply, it occurred to me that the fundamental question is whether providing a Named Interface is an intrinsic or extrinsic property of a subpackage. At the moment, Spring Modulith (if I've understood things correctly...) treats it as an intrinsic property i.e. in order to provide a NamedInterface, a sub-package must include that annotation within its own code. But I think it would be better to allow it also to be an extrinsic property - then, a maven/gradle submodule could be included within a Modulith module and treated as a NamedInterface in that context. Indeed, there might even be situations where the same included sub-package/sub-module should become a NamedInterface when included in one Spring Application but not when included in another Spring application - which highlights the need for NamedInterface being an extrinsic property that can be manage programmatically.

Many thanks for your help!

[ghferrari]

I read #851 but I wasn't sure if the OP was raising the same concern as me or not.

[odrotbohm]

For example, my particular use case is that I'd like the core of my Modulith modules to use hexagonal architecture, so I want to be able to define and build my core domain entities and use cases without any reference to Spring but then include them within a Modulith module.

I think this is a very common, very puristic approach to hexagonal architecture. And I also think it's a very hard one to defend completely because you have to raise the question of where to stop: what libraries are okay to refer to and which not? Was Joda Time okay to be referred to back in the days? If so, why? Any custom collection library? You can definitely argue “JDK-only”, my point is just that that's an arbitrary line being drawn.

It's worth remembering what goal the separation of concerns architectures was: to allow domain code to be tested and developed independently. In no way, it did say: avoid any kind of reference to a particular piece of code. It couldn't have because that's what code does: it refers to other code.

Rest assured that I've been involved in these discussions over decades. One of the reasons to start jMolecules was to avoid having to use Spring annotations in large parts of the code base. That said, we shouldn't throw out the baby with the bathwater here. The artifact structure of Spring Modulith has been deliberately designed to allow user code to depend on the minimally possible set of JARs in their production code if possible. That's why all metadata customizing annotations live in spring-modulith-api. I really don't see why an annotation on a package-info.java declaration would be in violation of Hexagonal Architecture. You could even use and run your code without the spring-modulith-api if needed.

That said, exposing the detection of named interfaces would add significant complexity to an already complex process (the detection of open application modules playing into that). Quite fundamentally, adding such a capability would take away the sovereignty of a module author to define which named interfaces exist and thus fundamentally break the encapsulation capabilities of the module. If you want a JAR to work with JPMS, it requires JPMS metadata. Similar, if you want a JAR to be an OSGi bundle. I'd argue that we're even a step ahead as our default is a convention based, single API (named interface) application module model.

Indeed, there might even be situations where the same included sub-package/sub-module should become a NamedInterface when included in one Spring Application but not when included in another Spring application - which highlights the need for NamedInterface being an extrinsic property that can be manage programmatically.

That's a valid use case, but I think you're jumping to conclusions too early. If you are picky about which named interface gets used by an application, you're likely to explicitly declare the allowed relationships anyway. Thus, app a could allow a dependency on foo :: ni1, while another one could be allowed to depend on foo :: ni2.

[ghferrari]

Many thanks for taking the time on this one. Good news - I'm persuaded you're right!