Pros/Cons of Canonical Data Model

soutchilin

Hi,

In the context of many systems in an enterprise, like multiple ERPs, some CRMs, etc. and using events as of "Event-Carried State Transfer" pattern, I have following question. Are there any recommendations from Solace architects about if it is a good idea to establish a canonical data model and, looking through the prism of DDD, to create a corresponding DDD-aware topics topology? Doing this would mean, that event schemas would be in CDM and the publisher must translate original messages before publishing events.

Canonical Data Model considered bad if not
Canonical Data Model pattern

Cheers,
Alexander

[Deleted User]

Hey @soutchilin, you've got the idea. Hierarchical topics + dynamic topic routing rules + multi-environment event mesh connectivity = support for DDD and CDM in its truest form. In the blog post you linked titled "Why You Should Avoid a Canonical Data Model," the author warns about standardizing objects and a central team forcing their will on application teams far and wide. In practice there's probably some truth to this, where large enterprises will have to spend cycles and cycles trying to define who gets to decide what the canonical data models are for the organization, teams are likely going to be pulled into meetings they can't contribute meaningfully to, etc. — but those problems are just enterprise tech, not CDM.

And his concerns about only having "one type" of Person, Customer, etc. objects aren't fair from my point of view.You can have raw event streams being published to some originating topic,

e.g. a topic structured like: {domain} / {app} / {object} / {verb} / {format}

.... where format for the originating data would say something like "raw," and then you can have intermediary translator microservices that localize that canonical event stream into any number of other formats required by other systems, perhaps adding reference data to the payload or aggregating raw feeds, etc. Point being — you're not forcing people to agree on ONE model, you're just making the data readily available.

I wouldn't want to get into an argument with the author about whether the situation I described above is CDM in its truest sense, but I think that the ethos of CDM is absolutely worth considering and incorporating into enterprise architecture. Agreeing on a baseline standardization for your core business data models and making that data available as event streams across all application environments using a technology like Solace event mesh will lead to a simplified approach to integration, creating data products, and building customer experiences.

Happy to continue the conversation and thanks for posting on the community!

For anyone reading:

DDD = domain-driven design

CDM = canonical data model

CRM = customer relationship management

ERP = enterprise resource planning, i.e. usually a db w/ tables for various business objects