Real World Applications/Event Driven Applications

Introduction

An event driven application is an application that reacts to external events.

Examples of events would be:

• A loan application has been accepted/rejected (commercial business).
• A new rostering schedule is ready for distribution to crew (airline system).
• A simulated car has hits another simulated car (commercial racing game).
• A HTML message has been received (web server).
• A key has been pressed (text editor).

The examples demonstrate that events can be anything from high level business events ("A loan application accepted/rejected") to low level events ("User pressed key").

In the following, I will show one way to architecture a Haskell system so that it can scale from small "toy" applications (dealing with low level IO events) to large scale "Enterprise" applications (dealing with high level business events).

Please note that the following is not the only way to attack the problem. So please contribute your (clearly superior of course) alternative way to do it here: Real World Applications

Events in Haskell

In the following, I define an "Event" to be a value describing something that has happened in the past. And yes this should really be called an "Event Notification" but life is too short :-)

Here is a straightforward way to define Events in Haskell:

data Event =
    EventUserExit            -- User wants to exit
  | EventUserSave            -- User wants to save
  | EventUserSaveAs String
  | EventUserUndo            -- User wants to undo
  | EventUserRedo            -- User wants to redo
  deriving(Eq,Show)

Events can be high level or low level depending on how "low level" in the system you are operating. Within a UI sub-system the events are typically low level (key pressed, window closed). In a large scale distributed system the events are typically high level business events (EventCustomerCreated <details>).

A Tiny Event Driven Haskell Application

Let's begin with a tiny event driven Haskell application:

module Main where

import Control.Monad (when)

import Domain   -- The (pure) "domain model" is defined here
import Event    -- The (pure) events
import UI       -- The (non-pure) UI (User Interface) is defined here

I am here using the term "Domain" to abstract away from the actual application domain. Fell free to use "Shipping" instead of Domain if your application area is shipping containers and "Game" if your domain is a game application. More info here: Domain Model

The Event module defines the events that both the Domain module and the UI module need to agree on.

The UI module contains some sort of User Interface. For now it doesn't really matter how the UI is implemented. All that matters is that it can somehow present the Domain to a user and get user events back. More on this later.

main :: IO ()
main = run newDomain []

The main function simply starts the event loop (run):

run :: Domain -> [Event] -> IO ()

run dm [] = do
  events <- uiUpdate dm
  run dm events

run dm (EventExit:_) =
  return ()

run dm (e:es) =
  run (domainUpdate dm e) es

"run" is where everything happens. The UI updates itself and returns one or more events. While there are still events to be processed, the domain will be updated one event at a time.

Consequences

The tiny application above is simple. However the way it is structured profoundly shapes how the application will scale:

• UI knows about Domain - not the other way around
• UI can be swapped without changing Domain.
• The Domain uses a value based API and not an interface based API
• Domain is pure.
• ...

Growing the Application

• Logging
• Testing
• Crash Recovery
• Undo/Redo
• Time
• UI
• Databases
• Client/Server
• Reporting
• Remove Control
• Event Sourcing
• Event Bus
• Security (Event Pattern Based)

Questions and feedback

If you have any questions or suggestions, feel free to mail me.