it-ebooks - F# for Fun and Profit eBook

This post is part of the F# Advent Calendar in English 2015 project.Check out all the other great posts there! And special thanks to Sergey Tihon for organizing this.

In this two-part mega-post, I'm stretching the simple turtle graphics model to the limit while demonstrating partial application, validation, the concept of "lifting",agents with message queues, dependency injection, the State monad, event sourcing, stream processing, and an interpreter!

In the , we covered the first nine ways of looking at a turtle. In this post, we'll look at the remaining four.

As a reminder, here are the thirteen ways:

• , in which we create a class with mutable state.
• , in which we create a module of functions with immutable state.
• , in which we create an object-oriented API that calls a stateful core class.
• , in which we create an stateful API that uses stateless core functions.
• , in which we create an API that uses a message queue to communicate with an agent.
• , in which we decouple the implementation from the API using an interface or record of functions.
• , in which we decouple the implementation from the API by passing a function parameter.
• , in which we create a special "turtle workflow" computation expression to track state for us.
• , in which we create a type to represent a turtle command, and then process a list of commands all at once.
• . A few notes on using data vs. interfaces for decoupling.
• , in which state is built from a list of past events.
• , in which business logic is based on reacting to earlier events.
• , in which the turtle API changes so that some commands may fail.
• , in which we make decisions in the turtle workflow based on results from earlier commands.
• , in which we completely decouple turtle programming from turtle implementation, and nearly encounter the free monad.
• .

and 2 bonus ways for the extended edition:

• , in which we encapsulate the details of a turtle implementation by using an Abstract Data Type.
• , in which we control what turtle functions are available to a client, based on the currentstate of the turtle.

It's turtles all the way down!

All source code for this post is available on github.

In this design, we build on the "command" concept used in the approaches, but replacing "commands" with "events" as the method of updating state.

The way that it works is:

• The client sends a Command to a CommandHandler.
• Before processing a Command, the CommandHandler first rebuilds the current statefrom scratch using the past events associated with that particular turtle.
• The CommandHandler then validates the command and decides what to do based on the current (rebuilt) state.It generates a (possibly empty) list of events.
• The generated events are stored in an EventStore for the next command to use.

In this way, neither the client nor the command handler needs to track state. Only the EventStore is mutable.

We will start by defining the types relating to our event sourcing system. First, the types related to commands:

Note that the command is addressed to a particular turtle using a TurtleId.

Next, we will define two kinds of events that can be generated from a command:

• A StateChangedEvent which represents what changed in the state
• A MovedEvent which represents the start and end positions of a turtle movement.

It is an important part of event sourcing that all events are labeled in the past tense: Moved and Turned rather than Move and Turn. The event are facts -- they have happened in the past.

The next step is to define the functions that convert a command into events.

We will need:

• A (private) applyEvent function that updates the state from a previous event.
• A (private) eventsFromCommand function that determines what events to generate, based on the command and the state.
• A public commandHandler function that handles the command, reads the events from the event store and calls the other two functions.

Here's applyEvent. You can see that it is very similar to the applyCommand function that we saw in the .

The eventsFromCommand function contains the key logic for validating the command and creating events.

• In this particular design, the command is always valid, so at least one event is returned.
• The StateChangedEvent is created from the TurtleCommand in a direct one-to-one map of the cases.
• The MovedEvent is only created from the TurtleCommand if the turtle has changed position.