Scope
To be of any use, context representations must be split into individual units upholding their identity whatever may happen. Such consistency is necessary to support the continuity of corporate identities.
Hence the distinction between transactional and non-transactional (aka master) data entities.
Objectives
Every object whose states have to be managed independently of activities must be consistently identified across systems. Those identities may be native (live beings) or built (devices), proper or derived, redundant (singleton) or irrelevant (copies).
In order to keep track of changes, representations mapped to individuals must be consistently identified by the business processes targeting them. That holds true for all symbolic objects, whether they represent individuals, physical or cultural, and whatever the coordinate system (address space), real or mythological, used to chart them.
A clear distinction must be made between identity and identifier. The former is an underlying constituent of business objects or processes, while the latter is only a symbolic setup used to fetch representations. As a corollary, identifiers are groundless until identities are founded. Looking for identifying attributes in order to establish object identities is like looking for stripes to identify horses.
Therefore, and before looking for identifying features, the point to consider is how identification mechanisms can affect the coupling between contexts and system, and consequently the architectures.
Guidelines
Some objects may come out as native individuals with built-in identities, so long as they can be sorted out from business concerns; others will directly begin as business constructs.
Objects with inbred identities are necessarily physical yet the opposite is not true since the identity of physical objects can be bound to other ones. Moreover, to be worthy of business consideration, they must be involved in some activities whose proper processing call for their state to be consistently and persistently recorded.
And since innate identities are set independently of business avatars, roles of objects with inbred identities, active or passive, must be documented as detached aspects.
It must be noted that whereas objects with business-based identities are necessarily documental, the opposite is not true: business aspects of objects with built-in physical identities are yet documental. As a corollary, objects with unique inbred identities may use alternative business identifiers as they appear in different business domains.
Whereas business-identified objects could theoretically be reduced to a single aspect, that would induce a frozen description of business concerns. Hence, if business objects have to support changing opportunities, identities and aspects must be documented apart from the outset.
If models are to support architectural concerns, principles must be set regarding the definition of persistency units:
- Single semantics: parts cannot be used without the root being in the know; otherwise individual changes in semantics or business rules will necessitate agreement between different organizational units. As a corollary parts and root must belong to the same domain.
- Single location: parts must be located where the root is, lest individual accesses involve unexpected dependencies.
- Single history: no event can affect a part without the knowledge of the root lest individual accesses by business processes be dependent on control rules set by different operational units.
Equivalent principles are used for execution units.
Persistency units are not limited to the representation of objects and may also record events and states of objects or processes. Some are represented individually, some as dependents, but the rationale behind the choice of representation must be straightforward: the symbolic representation of events and states cannot be modified. For instance:
- A customer (active physical object) gives his chariot (passive physical object) for repair (a documental object, open to amendments, is created and an actual process is initiated).
- Along the process a discussion occurs (event), with reference to the expected state (snapshots figured in grey) as documented with the repair agreement.
Synchronization
In parallel with activities synchronization, persistency synchronization, ie dynamic dependencies between persistent representations, can be described at symbolic or actual level:
- Symbolic synchronization provides a logical description of dynamic dependencies between persistency units independently of actual events, i.e as if controlled by logical clocks. Local synchronization is to be described by partitions of objects states, otherwise synchronization is to be applied to roles using time-dependent relationships.
- Actual synchronization deals with the persistent representation of objects whose states depends of actual events as generated by contexts, i.e is controlled by physical clocks. Events can remain implicit if synchronization is local, otherwise explicit descriptions are to be consolidated across domains.
The synchronization dependencies between persistent representations can also be expressed as rules.