Derivation rules are used to create symbolic representations using other symbolic representations. As such they do not reflect business objects or activities, only their representations, and can therefore be managed at will.

From symbol to symbol (Andy Warhol)

Derivation mechanisms can be applied to any symbolic representation:

  • Derived attributes, whose values are computed using native values.
  • Derived connections, which are built as shortcuts of native ones.
  • Derived objects, which are views defined on native objects.
  • Derived activities, which analyze native representations.
  • Derived states, which reflect native states.
  • Derived events, aka cascade, which are instant replicas of actual ones.


Since their footprint is circumscribed to symbolic representations (i.e system objects), derivation rules have no direct impact on couplings between systems and contexts. As a consequence, their implementation can be singled out and dealt with independently of the architecture. That may be especially useful for business rules managed according business opportunities.

2 thoughts on “Derivations”

  1. It’s nice to see that you recognise “derived states” as well as (the usual) “derived attributes”. But how do you distinguish between an attribute and a state.

    For instance, suppose I define a boolean “married” that is calculated as follows: “If there exists a valid Marriage Contract naming x, and x is alive, and the partner of x named in the Marriage Contract is also alive, then x is married.”

    Is “married” a state or an attribute of x?

    1. Derived attributes or states should never be directly associated to business objects or processes, only to their symbolic representation. In the Marriage exemple changes on actual civil status may be represented by (native) attributes or states depending on requirements. Then, derived attributes can be computed on native ones, and derived states on native ones. In other words derived states should never depend on domain events like change in contracts or person death. So “married” may be a derived attribute computed from Contracts and Persons; but it may also be a derived state shadowing the (native) state of Civil_Status.

Leave a Reply

%d bloggers like this: