9

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.

Punter Vicky
  • 875
  • 4
  • 11
  • 19
  • Would you happen to know the source of that statement? (for purposes of linking) – Jack Nov 08 '16 at 02:31
  • Sure Jack , it is here - https://www.nginx.com/blog/introduction-to-microservices/?utm_source=refactoring-a-monolith-into-microservices&utm_medium=blog – Punter Vicky Nov 08 '16 at 02:34
  • I suppose [this Wikipedia article](https://en.wikipedia.org/wiki/Canonical_schema_pattern) is what you are looking for. However, I don't find the article easy to understand. – Arseni Mourzenko Nov 15 '16 at 03:13
  • Thanks @ArseniMourzenko . I believe even in microservice architecture, the request and response have to comply to some data model. Not unable to understand yet as to why it is referred to as being rejected by microservice architecture . – Punter Vicky Nov 15 '16 at 03:17
  • 2
    Some data model yes, but seems to me, 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. A 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. ESB usually demands an enterprise data model (messages) which is going to be common for everyone in the bus. MS rejects to be attached to any external system constriction. – Laiv Nov 15 '16 at 07:59
  • But then, what seems confused to me is the previous sentence `They also very much avoid using ESBs and instead implement ESB-like functionality in the microservices themselves`. – Laiv Nov 15 '16 at 08:00
  • Thanks @Laiv. Your explanation makes sense to me. Please add an answer and I will accept :-) It will be useful for others who come across this and need an explanation. – Punter Vicky Nov 15 '16 at 16:24
  • @Laiv: Regarding ESB , I came across another post where they had mentioned that in traditional SOA approach , the pipes (ESB) are intelligent and endpoints are dumb and in MS approach , pipes are dumb and endpoints are intelligent. Since routing is kind of orchestrated by MS themselves & there is no common bus layer to orchestrate , is the author mentioning that MS has ESB like functionality? But then I thought API gateways sort of do the routing , so am confused too :) – Punter Vicky Nov 15 '16 at 16:28
  • @PunterVicky It could be a good subject for another question :-) – Laiv Nov 15 '16 at 17:20
  • Another better answer might happens still :-). Anyways glad to help you. – Laiv Nov 15 '16 at 17:35
  • @Laiv bounty is yours :-D – Punter Vicky Nov 15 '16 at 18:55

2 Answers2

6

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).

Laiv
  • 14,283
  • 1
  • 31
  • 69
1

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.

pnschofield
  • 334
  • 2
  • 5
  • `If you find that you have microservices making synchronous calls`. Not necessarily asynchronous callings. It could happens also with ESB asynchronous messages. I think it focus to the fact to be coupled to shared Schemas or data contracts. I assume that in MS architecture, it should be avoided any communication p2p between servicies. Communication should happend through applications instead of any internal (inner service layer) or external (ESB, queue, etc) layer – Laiv Nov 15 '16 at 23:28