Constructs

Constructs are the building blocks of your system. They help you define everything from the broad strokes of experience and information flow at the holistic level to the nitty-gritty details of business modeling and software modeling.

The holistic level constructs are displayed on the toolbar for easy access. Information Flow, Business Process, and Software Modeling constructs are located in the overflow menu.

Constructs can have Assets (Specs, Actors, etc.) attached to them.

The Holistic Level Constructs​

At the holistic level, we are only concerned with three constructs: Moments, Interfaces and Actions. These are located on the toolbar.

Moment​

You create a narrative with moments, from left to right. There's no hard and fast rules here, just split your narrative into moments and arrange them collaboratively with your team into a coherent flow. Spend as little or as much time as needed to ensure everyone understands the requirement using your business domain language.

Interface​

Describe the interface the actor uses to interact with the system. This might be a graphical interface, or perhaps it's a chat interface. For a system it may be an API. It could even be sensors.

Action​

An action is a placeholder for any system-level activity. There's no need to get too specifc here - we can always get more granular in the proceeding levels of modeling.

Information Flow Constructs​

Data​

When making a decision, an actor may require some data. Here we define the query that can bring back the required data.

Event​

If a decision is made and the relevant business rules and constraints are respected, we record the event in the historical record.

Similarly with external systems, if actions are taken upon them successfully (or not), or if they are somehow triggered (like the weather changing) then we record that historical event too.

These events result in two things:

1. the future enforcement of business rules
2. the creation of decision making data

Historical events are the lifeblood of the system.

Business Process Model Constructs​

Process​

When events occur, they sometimes cause a reaction. For example, when a customer has registered, we may want to send them a welcome email. These When>Then triggers are a kind of process called a Policy.

There are two other kinds of processes.

Sometimes we may make a decision that needs to trigger some sequence of sorts that spans across multiple business rules and external systems. In this case we might use a Process Manager.

And sometimes we may want to wait for a few different conditions to happen across a wide span of time before triggering a process. In this case, we use a Saga.

Constraints​

When the actor takes a decision, what constraints do we want to apply to decisions being made?

External System​

What external systems do we integrate with in order make decision? Or where decisions happen externally and we need to be notified?

These may be technical systems, but they can also be weather systems, or people systems too.

Software Model Constructs​

Resolver​

Data queries are resolved by resolvers. The resolvers may fetch data from a read model or a gateway if the data is external.

When the data comes from events, we may need to project those events into a read model before allowing resolvers to read from them.

Read Model​

Data model designed for querying and reading data.

Projection​

A mechanism to transform data into a structured format that is more suitable for queries, thereby creating or updating read models.

Gateway​

An internal endpoint that wraps access to an external system.

‍