A little explanation on events

One of the readers of my blog has sent me an e-mail with some questions on EDA. This event triggered me to publish this (hopefully) elucidative posting.

He started with the statement that many of the events seem to be based on the state of documents. Wrong! Events are not based on the state of documents, but it is the way around; the state of documents is based on events. An event occurs; the state of a document is not an event, but represents an event that happened (and is therefore often denoted as the event itself).

A business event is a specific occurrence that your business planned to react on. The process step where the event occurs will publish a document with the respective state. The next step in the flow will have a subscription on documents with this state.

As the state of a document represents (the occurrence of) a business event it is technically appropriate to use the publishing of the document as the trigger to activate the next process step (which is implemented as a software component). The publishing of the document is a detectable event that may (and will) creatively be used to represent the business event itself. But in fact it is a different kind of event.

This mechanism can be implemented by JMS-topics (if you use middleware). Or it may be implemented by instantiating objects (OO) of a class that represents a specific document state (if you build the mechanism in your applicationcode).

Example

The trigger of an order handling process is probably a customer placing an order. That is a business event, something your business planned to react on.

At that point you may start the flow. You could control the process flow based on the different states of the order. The order may have states like OrderAccepted, OrderRejected, OrderShipped, OrderInvoiced, OrderPayed etc.

A step in the process may be interested in orders with the state OrderAccepted. This step is interested because it probably is responsible for shipping the orders. The fact that the order is shipped is a business event that changes the state of the order to OrderShipped. Another process step is interested in orders with the state OrderShipped. This step will possibly create invoices.

The fact that an invoice is created for an order is a business event that results in the state OrderInvoiced and will trigger the invoice process flow. You may - by design - want to control a flow based on the states of the invoice, like InvoiceCancelled and InvoicePaymentReceived. So here starts the invoice as a document to control and track the state of the invoice handling flow that is branched of from the order handling flow.