What is the name of the interface-implementation pattern applied to modularisation?

Question

At work we have a project where we're pushing pieces of the monolith into modules. (A java project making smaller maven modules that we pull in via maven dependencies). The pattern we're using pushes each module into a 'pair' - with a module for the interface, and a module for the implementation.

The thought occurs that this pattern might have a name that better captures its reasoning. Whilst OO languages use this pattern for polymorphism, it seems like it might serve a slightly different purpose in this usage.

They hint at this pattern here:

You can also see in the following images that the sub-module package structure has been arranged on layer and type boundaries in that each module has its own model, repository (which contains interface definitions only) services and controller packages and that the layout of each module is identical at the top level.

My question is: What is the name of the interface-implementation pattern applied to modularisation?

Answer 1

Martin Fowler has previously described something similar using the term Published Interface:

Published Interface is a term I used (first in Refactoring) to refer to a class interface that's used outside the code base that it's defined in. As such it means more than public in Java and indeed even more than a non-internal public in C#. In my column for IEEE Software I argued that the distinction between published and public is actually more important than that between public and private.

The reason is that with a non-published interface you can change it and update the calling code since it is all within a single code base. Such things as renames can be done, and done easily with modern refactoring tools. But anything published so you can't reach the calling code needs more complicated treatment.

Fowler's complete article in .pdf format: Public vs Published Interfaces.

Answer 2

If your intent is to decouple an abstraction from its implementation, you may use a bridge pattern:

• your abstraction is the module interface. Consumer of your module know only this one.
• your actual implementation may have a slightly different interface (e.g. richer interface, or only building blocks and utilities, etc).
• your abstraction can be derived further, completely independently of its implementation.
• different concrete implementation could be used to implement the module, without having any effect on the abstraction and its dervates

I'm not sure that this is what you are looking for, or if this is overkill and you were looking simply for a facade to offer a public API to a well encapsulated private implementation