context definition in RIDDL represents the notion of a
Domain Driven Design (DDD).
A bounded context is an isolated portion of some knowledge domain.
Consequently, in RIDDL we defined a
DDD uses bounded contexts to divide complexity in large knowledge domains
into manageable portions. Since large knowledge domains are difficult for a
single human to comprehend in its entirety, DDD uses bounded contexts as a
primary structuring tool. Bounded contexts must be able to be fully comprehended
by any individual person. RIDDL utilizes both of these concepts the way DDD
Since bounded contexts are also subdomains, we distinguish them from subdomains with a few characteristics as discussed below.
As the name suggests, a
context has a finite and precise definitional boundary.
That means that it can be implemented easily because there is no vagueness.
A bounded context defines its boundary via a
that facilitates a common comprehension of the context between humans. Indeed,
this is one of its primary reasons for its existence: to assist in eliminating
the confusion and miscommunication of imprecisely defined concepts that human
languages tend to produce, even within a single language. For example, consider
the English word “order” in various contexts:
- restaurant - a list of food items to be made and delivered to a table
- backoffice - a list of things to be received from a shipper
- politics - a state of peace, freedom from unruly behavior, and respect for law
- mathematics - a sequence or arrangement of successive things.
- sociology - a group of people united in a formal way
- society - a rank, class, or special group in a community or society
- architecture - a type of column and entablature forming the unit of a style
- economics - a written direction to pay money to someone
- military - a directive or command from a superior to a subordinate
And that’s just the confusion resulting from one common business word!
A context’s ubiquitous language arises from the named definitions it contains. The names are specific terms used with precision by the subject-matter (knowledge domain) expert. Other practitioners (designers, developers, testers) must use these terms so that the language truly is ubiquitous and everyone is on the same page.
When modelling a system with RIDDL, the ubiquitous language boils down to
the names of the definitions that RIDDL permits inside a
context definition, as
shown in the list below. You can correctly think of a
language as the interface to that knowledge domain. It is very analogous to
an API (Application Programming Interface) as the interface to a program. The API