One of the sources of semantic coupling has to do with identifiers, and especially with synthetic identifiers. Most identifiers are just alphanumeric strings. Systems share those identifiers to ensure that both sides of an interface agree on the entity or entities they are manipulating.
In the move to services, there is an unfortunate tendency to build in a dependency on an ambient space of identifiers. This limits your organization’s maneuverability.
The trouble is that a naked identifier doesn’t tell you what space of
identifiers it comes from. There is just this ambient knowledge that a
Policy ID is issued from the System of Record for
policies. That means there can only be one “space” of policy numbers,
and they must all be issued by the same SoR.
I don’t believe in the idea of a single system of record. One of my rules for architecture without an end state is “Embrace Plurality”. Whether through business changes or system migrations, you will always end up with multiple systems of record for any concept or entity.
In that world, it’s important that IDs carry along their context. It
isn’t enough to have an alphanumeric
Policy ID field. You need a URN
or URI to identify which policy system issued that policy number.
Calendar service that tracks events by date and time. It
would seem weird for that service to keep all events for every user in
the same calendar, right? We should really think of it as a
Calendars service. I’d expect to see API to create a calendar, which
returns the URL to “my” calendar. Every other API call then includes
that URL, either as a prefix or a parameter.
In the same way, your services should serve all callers and allow them
to create their own containers. If you’re building a
service, think of it as a
Catalogs service. Anybody can create a
catalog, for any purpose. Likewise, a
Ledger service should really
Ledgers. Any client can create a ledger for any reason.
This is the way to create services that can be recombined in novel ways to create maneuverability.