Enterprise Data Model vs Bounded Context Data Models (MuleSoft)

It is critical to decide the data model for an API before planning the content of its structure. In this article, we'll discuss the Enterprise Data Model vs the Bounded Context Data Models.

Usually, the Enterprise Data Model is described as the Canonical Data Model, but for our purposes, we'll use the former term. There is exactly one canonical definition of each data type, which is reused in all APIs that require that data type, within all of the request-response actions in the product.

One definition of Data Structure that is used in APIs is related to different business processes of the API based product. An example of its application is booking software in resorts for the room, guest house, and playground.

In a Bounded Context Data Model, certain Bounded Contexts are recognized within resorts' booking by their usage of common terminology and insights. Every Bounded Context then has its individual, separate set of data type outlining, which is the Bounded Context Data Model. The Bounded Context Data Models of separate Bounded Contexts are formally unrelated, although they may share some names. All APIs in a Bounded Context reuse the Bounded Context Data Model of that Bounded Context. 

• The room booking Bounded Context has a distinct definition of booking that is formally unrelated to the definition of booking in the conference hall booking Bounded Context. 
• In the ideal instance, each API establishes its own API data model. Put differently, every API is in a separate Bounded Context with its own Bounded Context Data Model. 

Deciding Between the Enterprise Data Model and Bounded Context Data Models 

The integration of API data models between APIs adds overhead, which can become significant if APIs are owned by separate groups. Coordination effort applies to initial data modeling, to all changes to the API data model, and to the rollout of these changes to all APIs that share that API data model. This is one reason why Enterprise Data Models, although a seemingly attractive idea, are not usually acceptable. 

If there is no successful Enterprise Data Model, it is most pragmatic to use Bounded Context Data Models. If there is a prosperous Enterprise Data Model, then all Process APIs and System APIs should reuse that Enterprise Data Model as much as feasibly possible. 

The API data model of Experience APIs, on the other hand, is decided by the needs of the top-level API clients (such as user-visible apps) and thus is quite incredible to be obeyed by an Enterprise Data Model 

Aggregator or Customer Self-Service Mobile App/interface is unlikely to agree with an Enterprise Data Model. 

The Enterprise Data Model, even if it exists, typically does not define all data types needed by all APIs. Hence the decision for or against an Enterprise Data Model must be made on a per-data type basis. If the Enterprise Data Model specifies "policy" then that data type should be applied in all Process APIs and System APIs that deal with "policies" in their APIs, while those same APIs need to define "customer" by some other approach if "customer" is not part of the Enterprise Data Model.

To summarize, it is critical to decide the data model for API before planning the product thought process.