Canonical Data Model Best practices - sambos/Architectures GitHub Wiki

Canonical Data Model Best Practices

Standardized representation of Enterprise Data

There are many advantages of Canonical data model (CDM) for an organization and is an important step in promoting a standard data exchange within and across the organization. On the other hand it is also important to understand the side effects or the disadvantages when done incorrectly.

CDM is evolved from SOA concepts and may not be feasible for REST style architectures. Close evaluation is important before adopting it for microservices.

Canonical Data Models & Microservices - clarifying conflicting views

Advantages:

• Promotes consistency and standardized business vocabulary
• Reduces integration points and or data transformation steps
• Less maintenance & Ease of Governance

Disadvantages:

• Can result in maintenance and governance of multiple versions of CDM
• Increases development cost with changes to CDM
• For some systems, It can be an overhead for additional transformations. Especially when service requests need to be translated into canonical format and back into the format the consuming system can understand.
• Can become too big and hard to maintain and also very context sensitive.

Best Practices

• Appropriate versioning and name spacing strategy for the canonical data model must be developed that accounts for both major and minor changes to the model.
• Enforcing CDM on everyone in the org can backfire, especially when updating the fields which can reflect change in multiple services or applications.
• For microservices, define a light weight canonical model per functional domain. It should not be forced to function as a common model between all the microservices.
• Don’t push models onto teams; instead let them pull a model into their context when they see a value in doing so.
• Follow a BoundedContext pattern when dealing with large CDM - Using fields needed from CDM relevent to the sub-domain.