You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<h3class="hidden">See <ahref="https://domino-clj.github.io">here</a> for interactive documentation.</h3>
11
8
12
9
Domino is a data flow engine that helps you organize the interactions between your data model and events. Domino allows you to declare your business logic using a directed acyclic graph of events and effects. Whenever an external change is transacted to the data model, the graph determines the chain of events that will be executed, and side effects triggered as a result of the computation.
@@ -19,19 +16,19 @@ Domino explicitly separates logic that makes changes to the data model from side
19
16
20
17
Domino consists of three main concepts:
21
18
22
-
**1. Model**
19
+
### 1. Model
23
20
24
-
The model represents the paths within an EDN data structure. These paths will typically represent fields within a document. Each path entry is a tuple where the first value is the path segment, and the second value is the metadata associated with it. If the path is to be used for effects and/or events, the metadata must contain the `:id` key.
21
+
The model represents the paths within an EDN data structure. These paths will typically represent fields within a document. Each path entry is a tuple where the first value is the path segment, and the second value is the metadata associated with it. If the path is to be used for effects and/or events, the metadata must contain the `:id` key.
25
22
26
-
For example, `[:amount {:id :amount}]` is the path entry to the `:amount` key within the data model and can be referenced in your events and effects as `:amount` (defined by the `:id`). You can nest paths within each other, such as the following model definition:
23
+
For example, `[:amount {:id :amount}]` is the path entry to the `:amount` key within the data model and can be referenced in your events and effects as `:amount` (defined by the `:id`). You can nest paths within each other, such as the following model definition:
27
24
28
25
```clojure
29
26
[[:patient [:first-name {:id:fname}]]]
30
27
```
31
28
32
-
**2. Events**
29
+
### 2. Events
33
30
34
-
The events define the business logic associated with the changes of the model. Whenever a value is transacted, associated events are computed. Events are defined by three keys; an `:inputs` vector, an `:outputs` vector, and a `:handler` function.
31
+
The events define the business logic associated with the changes of the model. Whenever a value is transacted, associated events are computed. Events are defined by three keys; an `:inputs` vector, an `:outputs` vector, and a `:handler` function.
35
32
36
33
The handler accepts three arguments: a context containing the current state of the engine, a list of the input values, and a list of the output values. The function should produce a vector of outputs matching the declared `:outputs` key. For example:
37
34
@@ -45,7 +42,7 @@ The handler accepts three arguments: a context containing the current state of t
45
42
It's also possible to declare async events by providing the `:async?` key, e.g:
The handler accepts two arguments: a context containing the current state of the engine, and a list of output values.
85
82
86
-
#### outgoing effects
83
+
#### Outgoing Effects
87
84
88
-
Effects that declare `:inputs` will be run after events have been transacted and the new context is produced. These effects are defined as a map of `:inputs` and a `:handler` function.
85
+
Effects that declare `:inputs` will be run after events have been transacted and the new context is produced. These effects are defined as a map of `:inputs` and a `:handler` function.
89
86
90
87
The handler accepts two arguments: a context containing the current state of the engine, and a list of input values.
91
88
@@ -114,7 +111,7 @@ Let's take a look at a simple engine that accumulates a total. Whenever an amoun
@@ -131,7 +128,7 @@ This schema declaration is a map containing three keys:
131
128
* The `:events` key contains pure functions that represent events that are triggered when their inputs change. The events produce updated values that are persisted in the state.
132
129
* The `:effects` key contains the functions that produce side effects based on the updated state.
133
130
134
-
Using a unified model referenced by the event functions allows us to easily tell how a particular piece of business logic is triggered.
131
+
Using a unified model referenced by the event functions allows us to easily tell how a particular piece of business logic is triggered.
135
132
136
133
The event engine generates a direct acyclic graph (DAG) based on the `:input` keys declared by each event that's used to compute the new state in a transaction. This approach removes any ambiguity regarding when and how business logic is executed.
137
134
@@ -195,7 +192,7 @@ if the context is authorized before running the events as follows:
195
192
{:model [[:foo {:id:foo
196
193
:pre [(fn [handler]
197
194
(fn [ctx inputs outputs]
198
-
;;only run the handler if ctx contains
195
+
;;only run the handler if ctx contains
199
196
;; :authorized key
200
197
(when (:authorized ctx)
201
198
(handler ctx inputs outputs))))]
@@ -226,7 +223,7 @@ Effects can act as inputs to the data flow engine. For example, this might happe
0 commit comments