Pattern Sections
Pattern: Operational Data
Holder 
a.k.a. Transaction(al) Data Holder, Secondary Data Access and Modification
Context
A domain model, an entity-relationship diagram or a glossary of key business concepts and their interconnections have been specified; it has been decided to expose some of these data entities in an API by way of Information Holder Resource instances.
The data specification unveils that the entity lifetimes/update cycles differ significantly (for instance, from seconds, minutes and hours to months, years and decades) and that the frequently changing entities participate in relationships with slower-changing ones. For instance, fast-changing data may mostly act as link sources while slow-changing data mostly appear as link targets.1
Problem
How can an API support clients that want to create, read, update, and/or delete instances of domain entities that represent operational data: data that is rather short-lived, changes often during daily business operations, and has many outgoing relations?
Forces
Particularly relevant design time and runtime qualities when dealing with frequently changing data that is related to other data entities (including slower moving ones) include:
- Processing speed for content read and update operations
- Business agility and schema update flexibility
- Conceptual integrity and consistency of relationships
Pattern forces are explained in depth in the book.
Solution
Tag an Information Holder Resource as Operational Data Holder and add API operations to it that allow API clients to create, read, update, and delete its data often and fast.
Optionally, expose additional operations to give the Operational Data Holder domain-specific responsibilities. For instance, a shopping basket might offer fee and tax computations, product price update notifications, discounting, and other state-transitioning operations.
Sketch
A solution sketch for this pattern from pre-book times is:
Example
Lakeside Mutual, our sample application from the insurance domain, manages operational data such as claims and risk assessments that are exposed as Web services and REST resources (Figure 2).
All basic and advanced structural patterns can be applied when designing the request and response messages of the operations of the Operational Data Holder, for instance Pagination. Their applicability heavily depends on the actual data semantics. For instance, entering items into a shopping basket might expect a Parameter Tree and return a simple success flag as an Atomic Parameter. The checkout activity then might require multiple complex parameters (Parameter Forest) and return the order number and the expected delivery date in an Atomic Parameter List. The deletion of operational data can be triggered by sending a single Id Element and might return a simple success flag and/or Error Report representation.
Protect instances of this pattern with microservices infrastructure patterns such as Circuit Breaker that shuts down an outgoing communication channel in case of connectivity problems (to avoid an increase of the stress level of the overall system and its components) and Bulk Head that shuts down parts of a system (or services landscape) temporarily to protect other parts Nygard (2018). In the context of Information Holder Resources, outbound calls from Operational Data Holders to Master Data Holders can for instance be protected by a Circuit Breaker; closely related Operational Data Holders, for instance those forming/exposing an Aggregate in domain-driven designs Vernon (2013), can be guarded by a joint Bulk Head.
Are you missing implementation hints? Our papers publications provide them (for selected patterns).
Consequences
The resolution of pattern forces and other consequences are discussed in our book.
Known Uses
Most, if not all, business applications deal with multiple instances of this pattern; many of these are exposed in solution-internal APIs or community APIs as well as public ones (which leads to “Software-as-a-Service* offerings). A few known uses are:
- The Cargo Tracking system that serves as Domain-Driven
Design Sample Application keeps operational data such as
Cargo,RouteSpecificationandItineraryprogress (leg/hop arrival is expressed as handling events) and exposes them to the application frontend via its (rather thin) application and presentation layer. See the root entity of the Cargo Aggregate and its contained entities. - Several of the “method families” in the Slack Web API are data-oriented; the “conversations” family, for instance, deals with operational data.
- Tweets and posts in social networks such as Twitter and Facebook also qualify as known uses if/as exposed in Public APIs.
As a process integration platform, Terravis Berli, Lübke, and Möckli (2014) deals with many different process types and thus many transaction-specific data holders. For instance, when a loan is transferred from one bank to another, the securities also have to be transferred – in exchange for payments. Within this process, the two involved banks must negotiate the terms by offering (and accepting) a payment promise and a creditor release. These two entities depend on each other, and are only relevant until the transaction has been completed. Thus, they represent operational data (rather than master data).
Account endpoints in core banking APIs such as Brandner et al. (2004) also qualify as pattern instances; actually, the accounts can also be seen to be long-lived master data, while account transactions are truly operational.
More Information
Related Patterns
The alternative to this pattern are Master Data Holder and Reference Data Holder (instances of which live longer and have more incoming references); a less data- and more action-oriented alternative is Processing Resource. All operation responsibilities patterns including State Creation Operation and State Transition Operation can be used in Operational Data Holder endpoints.
The Data Type Channel pattern in Hohpe and Woolf (2003) describes how to organize a messaging system by message semantics and syntax (e.g., Query, Price Quote and Purchase Order). These channel types can be organized according to the terminology introduced by our pattern category Responsibility Patterns.
Operational Data Holders referencing other Operational Data Holders may chose to include this data in the form of an Embedded Entity. On the contrary, references to Master Data Holders often are not included/embedded but externalized via Linked Information Holder references.
Other Sources
See Master Data Holder for a brief discussion of the connection of our patterns to Domain-Driven-Design Evans (2003).
“Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives” Rozanski and Woods (2005) has an information viewpoint.
“Data on the Outside versus Data on the Inside” by P. Helland explains design forces and constraints for data exposed in APIs and application-internal data Helland (2005).
References
The context of this pattern is the similar to that of its sibling pattern Master Data Holder, but acknowledges and points out that the lifetimes and relationship structure of these two types of data differs (in German: “Stammdaten” vs. “Bewegungsdaten”, see Ferstl and Sinz (2006), White et al. (2006)).↩︎