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.
|