Introduction
Distributed software systems are inherently complex, as the jobs of multiple people and software components need to be aligned and integrated with each other into a coherent business process.
Before you dive into code, you should take some time to understand and model this process.
By the end of this part of the Tutorial, you will:
- Have a grasp of (a part of) a typical e-commerce process.
- Be able to read an Event Model.
- Understand that information flow is more important than data structure.
- Realize not all data is equal.
- Be introduced to the 9 processing patterns on which the MessageHandler way has been based.
Model of an e-commerce process
Below you see an event model of the business process you will build during this learning path.
It is representative for (a part of) a typical e-commerce process:
- A buyer selects a product from the product catalog, and places an order to buy that product at the presented price.
- The seller will be notified of thisbooking, validates that it can be fulfilled and confirms the sale.
- As a result the buyer will receive a confirmation of the sales order by email.
Event modeling
The drawing style, used to represent this business process, is called an event model.
It provides a visual overview of the interaction, between the people and software components involved in the process, as time progresses (from left to right).
People
The swimlanes at the top of the model represent the people, along with the forms or pages they interact with.
In this case you distinguish:
- The buyer
- The seller
Reading the model from left to right, you see that the buyer
- Fills out a form to place an order
- After doing so, the buyer sees a page showing the placed booking
- And, after a while, the buyer will get an email notification when the order has been confirmed.
In the mean time, the seller
- Saw the purchase order pop up
- Confirms that the order can be fulfilled
On behalf of the seller, the system automatically executed some tasks.
- Newly received orders get indexed and presented to the seller
- A confirmation email gets sent to the buyer after confirming the sale
Autonomous components
At the bottom of the model, you differentiate the autonomous software components that will make up the system.
As the MessageHandler way of building distributed software dictates, these components represent sub processes.
For the sake of keeping the learning path short, the model is limited to only a few sub processes
- Order booking: The transition from a purchase order to a sales order
- Sales order indexing: Makes the order searchable by the seller
- Sales order confirmation: Notifies the buyer when the seller confirms the order can be fulfilled.
A full e-commerce process would entail more steps of course, including catalog management, pricing, payment, packing, shipping, refunds, etc...
After having completed this learning path you should be able to add those aspects to the process yourself, by repeating the same steps over and over again.
The model already shows where the output of the catalog management and pricing sub processes could feed into the booking process.
Commands, Events and state
The MessageHandler approach is based on the assumption that, in distributed systems, the nature of information flow is more important than the structure of the data itself.
Data structures are a result of the business process, they serve the need for interaction and data exchange between humans and the software components.
But still, not all data structures are the same!
In an event model you can differentiate three types of data structures being exchanged.
- Commands (blue post-its): Commands capture the users intent. They contain data to transition into a future desired state. Their outcome is uncertain.
- Events (orange post-its): Events record decissions taken, usually as a result of responding to a command. They occur in the past and have a certain outcome.
- State (green post-its): Represents the data and structure of an entity at a given point in time. This data and structure slowly evolves over time.
As events are the most stable of data structures recognized, they form the basis of event modeling and will take a prominent position in any system developed with MessageHandler.
Processing patterns
Given there are only 3 types of data structures in any given system, there are also only 9 transitions between them.
For each of these transitions MessageHandler offers a go to design pattern, which is supported by the libraries.
These 9 patterns are:
| In \ Out | Commands | Events | State |
|---|---|---|---|
| Commands | Delegation | Aggregate Root | Downstream Activity |
| Events | Reaction | Event Processing | Projection |
| State | Task Processing | Event Generator | State Transformation |
Over the course of this learning path, you'll dive into the patterns one by one.
Summary
Now that you have an overview of what the business process will look like and understand the MessageHandler approach to building systems, you’re ready to actually start building it.
What’s coming next?
In Part 3 of the Tutorial, you’ll implement one of the most common processing patterns: an Aggregate Root.