Deep dive into the Published Language

Some thoughts:

DDD re-distilled – Speaker Deck: Published Language as a free team relationship and lowest team communication / independance.

Unshackling Integration: Part 1 – Moving Beyond Canonical Data Models – Knowledge base / Blog – webMethods – Software AG Tech Community & Forums: very interesting:

‘As systems evolve the canonical model needs to evolve’ – how to do that with industry standards governed by a consortium?
Microservices, with their decentralized nature focus on individual services, with these parts promoting autonomy and scalability, challenging the dominance of central created and maintained integrations.
Any change to a CDM is complex because of the dependencies this has with all other integrations relying on these
As such, CDMs are typically centrally controlled and governed which creates an anti-pattern to agility as you become reliant on a central implementation and commonly a central controlling team with a lot of governance and maintenance overhead which creates a bottleneck, and results in slower integration speeds.
A good API only takes in the data it needs and returns the subset of data associated with this. If you’re creating an API that uses canonicals, this typically would go against good practice, as both APIs and especially Microservices advocate for smaller , and self-container services, making a CDM unpractical.
Data transferred should be kept to a minimum, to avoid the pitfalls of global internet communication links such as bandwidth, data transfer speeds and latency. Information security practices would also state to only transfer the information needed as this reduces risk.
‘one size fits all’ canonical model…. Designing contracts are now often a domain-driven initiative, giving the owners of each domain the decision-making rights,
Use API when you’re going outside of boundaries, not when you’re already inside!

Why is a Canonical Data Model an Anti Pattern | by Teiva Harsanyi | Medium: see also comments – Canonical model as described in the EIP is for integrations, not for microservices. Enterprise integrations apply very different patterns than microservices or DDD. In microservices, a canonical model is indeed an antipattern, but at the integration layer it is quite useful in many scenarios.

Data Modeling i API First vs Canonical Data Modeli… – Google Cloud Community

Zimmermann:

Using the same DATA ELEMENT structures across an entire API or a set of in-house services allows for easier composition of the services. Enterprise Integration Patterns
calls such an approach a “Canonical Data Model” but advises to handle it with care [Hohpe 2003]. One can consider microformats [Microformats 2022] in such a standardization effort. (searched for ‘ Published Language’.)