Comment by bertylicious
2 days ago
How does this relate to domain-driven design? It seems to be at odds with it, because in DDD it's kind of expected that the same concept will be represented in a different way by each system? But to be honest, I didn't read the whole blog post because of the UML vibes.
> How does this relate to domain-driven design?
The "Domain" in `upper:DomainModel` is the same D as in DDD (Domain-Driven Design) as the D in DGS (Domain Graph Service).
> in DDD it's kind of expected that the same concept will be represented in a different way by each system
In UDA, those concepts would explicitly co-exist in different domains. "Being the same" becomes a subjective thing.
It doesn't. It's a blessing that they avoided the term "ubiquitous language" because that's almost exactly the dual of this concept, although people who have only ever heard the words and not dug any deeper won't know what the difference is.
Seems to be enforcing ‘ubiquitous language’ at the machine level - not some kind of mathematical dual where one is invertible to the other - but enforcing soft skills as hard skills.
what makes a duck a duck? when we know which tables we can find it in
Except that "Ubiquitous Language" is supposed to refer to terminology within a specific Bounded Context. In DDD it is desirable and expected that there is a mapping between them. This proposal tries to entirely erase Bounded Contexts. This is what I mean about people not understanding the words.
So in the sense of "what do we do about terminology not matching across an organisation" this and DDD are literal opposite solutions: one says "erase differences with a central definition (and bear the coordination costs)" while the other says "encourage differences with local definitions (and bear the mapping costs)".