Comment by kiitos
2 days ago
> Core business concepts like ‘actor’ or ‘movie’ are modeled in many places ... teams re-model the same business entities in different systems, leading to conflicting definitions that are hard to reconcile.
There is no singular universal consistent definition of any concept like "actor" or "movie" or whatever else. These are all concepts that are well-defined only within a specific domain. The business domain concept of an "actor" is well and good and probably the most important and top-level user-facing concept of that term -- that doesn't mean that this business-domain definition is somehow authoritative, or comprehensive, or in any way some kind of superset-composite description of any/all other domain definitions of that same term.
Reconciliation of domain-specific concepts like these requires higher-level coordination across separate domains, it's not something you can do within individual domains or domain-specific services. If discrete domains/services needed to abide the same business-defined concept of whatever concepts, then that would subvert the main purpose of having separate domains/teams in the first place.. !
They’re not pushing a single canonical schema.
Each team still owns its local RDF graph for concepts like actor or movie. What UDA adds is a shared graph of mappings that translate between those local models whenever another team needs them.
Traditionally such translations live in scattered adapter code, which hides lineage and adds opacity - particularly as systems proliferate. By expressing the mappings as RDF triples inside UDA’s knowledge graph, they become versioned, queryable, and reusable. No more spelunking through layers of service code to understand how one team’s actor becomes another’s.
As a result, discrete teams/domains remain independent while the interconnections/relationships become first-class and introspectable. This enables coordination without centralization.
> What UDA adds is a shared graph of mappings that translate between those local models whenever another team needs them
Every such mapping is a composite definition, composed over two discrete concepts, each of which is owned/managed by discrete teams. Who gets to define/own/maintain these composite mappings? They're separate concepts, "on top of" the things they map, meaning they only exist in terms of specific versions of the underlying entities. It's just not as simple as it seems, or as is being implied here...
> As a result, discrete teams/domains remain independent while the interconnections/relationships become first-class and introspectable. This enables coordination without centralization.
What's being described here is for sure a centralized collection of definitions of mappings between interconnections/relationships.