# Canonical Data Model

> Agree on one shared data language — translate to/from it at every integration boundary.

- **Category**: Integration
- **Subcategory**: Message Transformation
- **Canonical URL**: https://designpattern.fyi/patterns/canonical_data_model/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Enterprise customer data hub — 8 systems (CRM, ERP, billing, support, analytics, mobile, web, partner portal) all exchange customer data. Canonical CustomerProfile model defined. Each system has 2 translators. Total — 16 translators vs 56 point-to-point. Future 9th system — add 2 translators, not 8.





## Trade-offs


### Advantages

- Reduces translation complexity from O(N²) to O(N)

- Single place to evolve the shared data language

- New systems only need to implement 2 translators, not N

- Creates a stable integration contract independent of any single system




### Considerations & Drawbacks

- Canonical model design is a major upfront investment — requires domain expertise

- Canonical model can become the lowest common denominator — losing source richness

- Organizational alignment needed — all teams must agree on and adopt the model

- Canonical model evolution requires coordinated updates across all translators







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/CanonicalDataModel.html)