Skip to content
Software Architecture Guide

Canonical Data Model

Explanation

Section titled “Explanation”

Different applications often send data in different formats. If every system must talk to every other system, each pair needs its own translation. With n systems, that means n × n translation paths.

A Canonical Data Model removes most of that work. You design one data model that does not depend on any specific application. Each system then translates only to and from that shared model, which acts as a central hub. The result is n paths instead of n × n.

The goal is to minimize dependencies between applications that use different data formats. A system no longer needs to know the format of the systems it talks to. It only needs to know the shared format.

A related pattern is the Normalizer (see the article “Normalizer”). It routes each incoming message type through a matching Message Translator (see “Message Translator”). Every message then arrives in the shared format. One published example involves over 1,700 affiliates.

Designing the shared model is hard. A single model for a large enterprise tends to be very large, abstract, or both. That makes it hard to understand. One suggestion is to use several canonical models instead of one. You then translate between the parts where they overlap.

Example

Section titled “Example”

A retailer has an order system, a warehouse system, and an invoicing system. Each uses its own order format. Instead of building a translator for every pair, the team defines one shared “Order” format. Each system gets one translator to and from it.

Trade-offs

Section titled “Trade-offs”
  • Overkill for small setups. With only a few applications, the approach looks complicated and brings little gain.
  • Hard to design. A model that covers a whole enterprise tends to become large or abstract, so people struggle to understand it.
  • Possible remedy. Several canonical models, with translation between overlapping parts, can replace one big model.

Each system translates only to and from the shared canonical model.

Diagram source 
flowchart LR
 A[System A] <--> C((Canonical model))
 B[System B] <--> C
 D[System C] <--> C
 E[System D] <--> C

Checks

Section titled “Checks”
  • The document justifies the canonical model by the number of integrated applications, since it is overkill for only a few.
  • The canonical model is independent of any specific application.
  • The document states whether one enterprise-wide model or several canonical models with translation between overlaps are used.
Section titled “Related”

Sources

Section titled “Sources”