When I was reading about microservices on this site, I came across the below statement. What is meant by a canonical schema? Isn't it same as domain model?
The Microservices Architecture pattern also rejects other parts of SOA, such as the concept of a canonical schema.
Apologies in advance for relying on the @ArseniMourzenko comment, but once I started to read the Wikipedia I immediately understood what Canonical Schema means.
Here OP's comment that focuses on the real doubt
I believe even in microservice architecture, the request and response have to comply to some data model.
Some data model yes, but seems that the article is referring to a "shared" or "common" data models between 2 or more services.
The Canonical Schema is a pattern meant to save services from in runtime data transformations. It also saves you from duplicating code. But you are then coupling your service to an external data model too.(See diagrams at the Wikipedia's page linked above)
It's a sort of common "language" between services.
So looks like the article is emphasising on the total independence of the MS from the "ecosystem" where it lives at.
Take for example the mention it does to ESB.
They also very much avoid using ESBs and instead implement ESB-like functionality in the microservices themselves.
ESB usually demands an enterprise data model (messages) which is going to be common for everyone attached to the bus.
So, back to the article, seems that the author is pointing to the fact that MS rejects to be attached to any external system (and their constraints).
Microservices is all about tight cohesion and loose coupling. Within a microservice, you have tight cohesion, but between microservices, you have loose coupling and therefore you want to avoid any shared schemas or data contracts. If you find that you have microservices making synchronous calls to each other in a way that demands they share a common schema, that can be an indication that you have defined your service boundaries incorrectly.
Microservices should be closely aligned to Bounded Contexts, in Domain-Driven Design parlance.
