Skip to content

Overview

In this section we will explore the concepts and ideas that RIDDL uses. This is not about the RIDDL language syntax, just the concepts of the language.

Definitions

RIDDL consists only of definitions that define the design of the desired system.

Definitional Hierarchy

Definitions in RIDDL are arranged in a hierarchy. Definitions that contain other definitions are known as branches. Definitions that do not contain other definitions are known as leaves.

This is done simply by having an attribute that lists the contents of any definition:

  • contents: The contained definitions that define the container. Not all definitions can contain other ones so sometimes this is empty.

Simplifications

The valid hierarchy structure is shown below, but to make this hierarchy easier to comprehend, we've taken some short-cuts :

  1. All the common attributes have been omitted for brevity but are implied on each line of the hierarchy.
  2. We only descend as far as a Type definition. Whenever you see one, you should infer this hierarchy:
  3. Types

Hierarchy

With those clarifying simplifications, here's the hierarchy:

                              ┌─────────────────────────────────────────────┐
                              │                    Root                     │
                              └──────────────────────┬──────────────────────┘
                                                     │
                              ┌──────────────────────┴──────────────────────┐
                              │                   Domain                    │
                              └──────────────────────┬──────────────────────┘
                                                     │
                 ┌───────────────────────────────────┼───────────────────────────────────┐
                 │                                   │                                   │
           ┌─────┴─────┐                       ┌─────┴─────┐                       ┌─────┴─────┐
           │  Context  │                       │   Epic    │                       │   Type    │
           └─────┬─────┘                       └─────┬─────┘                       └───────────┘
                 │                                   │
    ┌────────────┼────────────┐                ┌─────┴─────┐
    │            │            │                │   Case    │
┌───┴───┐  ┌─────┴─────┐  ┌───┴───┐            └─────┬─────┘
│Entity │  │ Projector │  │ Saga  │                  │
└───┬───┘  │ Adaptor   │  └───┬───┘            ┌─────┴─────┐
    │      │ Processor │      │                │ Statement │
┌───┴───┐  │ Streamlet │  ┌───┴───┐            └───────────┘
│ State │  │ Function  │  │  Saga │
└───┬───┘  │ Handler   │  │  Step │
    │      │ Group     │  └───┬───┘
┌───┴───┐  │ Type      │      │
│Handler│  └───────────┘  ┌───┴───┐
└───┬───┘                 │ Stmt  │
    │                     └───────┘
┌───┴────┐
│OnClause│
└───┬────┘
    │
┌───┴───┐
│ Stmt  │
└───────┘

Detailed Containment Reference

Container Can Contain
Root Domain, Module, Author, Version, Copyright, Include, Import
Module any top-level definition, flat and unordered
Domain Type, Epic, Context, Domain (nested), Saga, User, Author, Repository†, Connector†, Version, Copyright, Include, Import
Epic Case → Interaction, Type, shown by, Include
Context Entity, Projector, Saga, Adaptor, Repository, Processor, Connector, Group‡, + processor contents
Entity State, + processor contents
State Handler, Invariant
Projector updates, + processor contents
Saga SagaStep → Statement, Inlet, Outlet, Function, Include
Adaptor processor contents
Repository Schema, + processor contents
Processor processor contents
Function Statement, Type, Function (nested), Include
Handler On Clause → Statement
Group Group (nested), contains, Input, Output, shown by
Invariant a Value condition

† at domain scope only when the definition genuinely spans several contexts ‡ only in a context with the application intention

Processor contents — every processor may contain: Handler, Function, Type, Constant, Invariant, Inlet, Outlet, nested Processor, Connector, Version, Copyright, Comment, Include.

New in RIDDL 2.0

Four concepts are new, and one changed shape:

  • Module — a flat, named collection of any top-level definition, which absorbed the deprecated nebula
  • Version — one component of a composed version coordinate
  • Copyright — a named notice, inherited nearest-first
  • Standard Module — the predefined stream terminators every model can use without importing anything
  • Processor — unified: every processor kind now bears ports and carries a shape derived from its arity

Next

When you're done exploring all the concepts, check out our guides next.

Full Index

The pages in this section cover each RIDDL concept in detail. Use the navigation menu to explore individual concepts.