RIDDL Documentation
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage


A context definition in RIDDL represents the notion of a bounded context from Domain Driven Design (DDD). A bounded context is an isolated portion of some knowledge domain. Consequently, in RIDDL we defined a context inside a domain. 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 intends.

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 ubiquitous language 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 contexts ubiquitous 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

To further your understanding, watch this 34-minute video by Eric Evans from DDD Europe 2020 conference

Occurs In