Posted on

Recognizing Bounded Contexts and Bounded Context Data Models

Recognizing Bounded Contexts and Bounded Context Data Models

Because accommodation reservation does not have an outlined, strong enterprise data model, it uses bounded context data models. To recreate this process:

  • Identify bounded contexts
  • Assign each API to precisely one bounded context, based on the defining (governing) data types for that API Anypoint Platform Architecture Application Network
    • The defining data type of the "Single Room Search SAPI" is single room booking
    • If an API has no clear set of defining data types, or if those data types are used in significantly different variations in different operations of that API, then the API is likely too coarse-grained and should be broken up
    • Designate a bounded context data model for each bounded context, based pragmatically on the needs of the APIs in that bounded context
  • Reuse the bounded context data model in the APIs of that bounded context

How to Identify Bounded Contexts

  • Begin with the organizational building by directing basic units where important business concepts are used in a coherent and uniform way
    • Examples include single room booking, resort booking, party hall booking, lunch or dinner booking, customer relationship management, etc.
  • If you have any doubt, favor smaller bounded contexts
  • If you are still unsure, put each API in its own bounded context
    •  Note: It is not recommended to adjust API data models within APIs

A bounded context data model should be published as RAML fragments (RAML types, possibly in a RAML Library) in Anypoint Design Center and Anypoint Exchange so that it can be easily re-used in all APIs in a bounded context.

Posted on

Microservices Powered By Domain-Driven Design

Have you been finding it difficult to model the boundaries of your system’s microservices? Have you been slowed down by the Technical complexity of your codebase? Has your team been stepping on each other’s toes?

If answers to any or many of such questions are yes, then Domain-Driven Design is likely useful to your Team!

Posted on

Domain Events Versus Change Data Capture

The building of change data capture (CDC) and event based systems have recently come up several time in my discussions with people and in my online trawling. I sensed enough confusion around them that I figured this was worth talking about here.
CDC and event-based communication are two very different things which look similar to some extent, hence the confusion. Beware — confusing one for the other can lead to very difficult architectural situations.

What Are These Things?

Change Data Capture (CDC) typically alludes to a mechanism for capturing all changes happening to a system's data. The need for such a system is not difficult to imagine — audit for sensitive information, data replication across multiple DB instances or data centers, moving changes from transactional databases to data lakes/OLAP stores. Transaction management in ACID compliant databases is essentially CDC. A CDC system is a record of every change every made to an entity and the metadata of that change (changed by, change time etc).
You may also enjoy: Change Data Capture (CDC) With Embedded Debezium and Spring Boot
I have written about events on this blog before and have described them as announcements of something that has happened in the system domain, with relevant data about that occurrence. At a glance, this might seem to be the same as CDC — something changes in a system and this needs to be communicated to other systems — which is exactly what CDC is about.

However, there is a key distinction to be made here. Events are defined at a far higher level of abstraction than data changes because they are meaningful changes to the domain. Data representing an entity can change without it having any "business" impact on the overall entity that the data represents. There can be several sub-states of an order that an order management system might maintain internally but which do not matter to the outside world. 

An order moving to these states would not generate events but changes would be logged in the CDC system. On the other hand, there are be states that the rest of the world cares about (created, dispatched etc) and the order management system explicitly exposes to the outside world. Changes to or from these states would generate events.