The technique described on this site attempts to extrapolate Alan Kay's concept of biological (cellular) automota coordinating their behaviour by means of message exchange. The site describes terms such as:
These concepts are used widely in Domain Driven Design (DDD) but the chosen characteristics (both strategic and
tactical) are specific to DDD.
Below, I define the strategic characteristics of the each concept as applied to this technique.
I point out similarities and differences between this technique and DDD.
I also include some some initial hints of tactical patterns used to apply them.
Concepts differing widely from DDD counterparts
Domain
Within DDD, there is a focus on defining a clear domain expressed in a ubiquitous language (and a corresponding domain model). Often the desire for a cleanly-modelled domain pushes parts of the implementation outside of the domain model - e.g. "infrastructure" or "UI". The technique described in this site explicitly demands that the "core" domain encompasses the entirety of the implementation.
Entity
An entity is is the locus of all behaviour.
An entity is something which has a unique identity due only to how it behaves.
Although entities produced by the same factory may behave similarly, they are distinguished by internal state
which causes them to respond in a unique way to messages which they receive.
An entity should usually not be identifiable other than by the way it behaves in response to messages.
The goal of this techinque is for entities to collaborate purely via message exchange.
Entities are expected to detect messages emitted by other entities and decide whether or not to act upon those
messages.
Value
Like DDD value objects, value objects are entirely defined by the value of their attributes.
Values may not exhibit behaviours (beyond the representation of their data).
Unlike DDD, a value object may be an identifiable piece of data with its own identity, specified by one or more
attributes (acting as a key).
Values are frequently used as the value-bearing portion of a message which can received or emitted by an
entity.
Concepts similar to DDD
Aggregate root
Similar to DDD, aggregate roots are entities which are responsible for the coordination of other entities via (re-)distribution of messages to entities contained within the aggregate.
Bounded context
Like DDD, a bounded context represents the chosen boundary within which to implement one or more parts of a
domain.
Each message belongs to a bounded context and its meaning is defined by its owning context.
Messages exchanged by contexts are often handled by a single entity which is responsible for marshalling external
messages.
Messages owned by a bounded context are intended to flow freely within a bounded context, but not within other
bounded contexts.
Lack of source-code segregation
It should be noted that using this technique, bounded contexts may reuse entities and values found in other contexts. This is because a bounded context is modelled as a run-time structure of objects (not statically defined folders, files, factories or classes/functions)
Factory
Factories are used to create Entities and Aggregate Roots. Without Factories it is not possible to instantiate Entities.
What is a message?
Message
A message is a signal sent to/from an entity and/or aggregate root.
It is similar to the concept of an "event" or "Domain Event" in DDD in that it usually describes something
which has happened.
However, messages are the bread-and-butter of this technique.
They are not reserved for course-grained interactions.
A message consists of two parts:
- Message type
- Message values
Message types are represented by unique values (JavaScript symbols, URLs and UUIDs are all potential
implementation options).
Message values are plain data structures without any behaviour (JSON documents, JSON-LD docments and plain-old
JavaScript objects which can be created by hydrating JSON, are all good candidates.)