Pattern 08: Model Data Control Points
Improve the definition of data control points as a necessary step toward ensuring data encapsulation.
Relationships
Main Description

Context

Most software systems that exist in an enterprise store data using some sort of persistence technology. Normally, but not always, this is a relational database.

No matter what the persistence technology, there are some element-level artifacts where the data is stored (for example, a table in a relational database or an object in an object database). We consider that element-level artifact to be controlled by a software component if the only thing that is allowed to access the state it contains is that software component.

Problem

Not having clear data control points makes it impossible to ensure data encapsulation.

Forces

  • It is difficult to know which component has encapsulated a specific data item.
  • It is difficult to know what data items a component is responsible for.
  • For a given component and data item, it is difficult to know whether the component implementation can access the data item directly or whether the component has to access it through the interface of another component.

Solution

Assign data control point to Participants that provide atomic business application services. Model this data control point using information types.  For each such Participant we create an information type to represent each of the data items that it manages.

Note the following:

  • These information types are black box representations of the state that the Participant owns.
  • By control we mean that the Participant has exclusive access to the data instances in the data structure (internal, white box) that matches the information type (external, black box).
  • Information types are very useful when using pre-conditions and post-conditions to describe the behavior of service operations. In other words, the pre-conditions and post-conditions describe changes to the state owned by the Participant in terms of the info types.
  • Information types can be (and should be) derived from domain types.
  • It is not uncommon for more than one information type, each belonging to a different Participant, to be derived from the same domain type. This is especially common when one Participant only has to store a reference to the identity of a certain business thing, while another Participant persists actual instances of the thing.

Rationale

Understanding data control points is very important in our service architecture. Modeling info types to represent the data controlled by each Participant means that:

  • We can now tell which component has encapsulated a specific data item by checking to see which info types are derived from the domain type, and then checking which Participant owns the info type.
  • To understand what data items a component is responsible for, we look at which info types its Participant controls.
  • To determine whether a component implementation can access a data item directly, verify whether the corresponding info type is controlled by its Participant.
More Information