12 Things You Should Know About Event Sourcing

Are you aware that storing and updating current state means loosing important data?

Event sourcing is a way to solve this problem. It is the technique of storing state transitions rather than updating the current state itself.

Event sourcing has some more benefits:

  • Complete audit-proof log for free
  • Complete history of every state change ever
  • No more mapping objects to tables
  • Distribution support
  • CQRS (Command Query Responsibility Segregation) support
  • Natural fit for domain-driven design and functional programming
  • Be prepared for unanticipated use cases in the future (for free)

State transitions are an important part of our problem space and should be modelled within our domain — Greg Young

When I first encountered the concept of event sourcing and CQRS and looked at some sample applications, I had the impression that it must be extremely difficult to implement. But later I found out that event sourcing is easier than I first thought, especially when it is expressed with functional programming.

Here are 12 things about event sourcing that should help you to get started today.

Continue reading →

SameGame with F# and Fable: Functional programming meets JavaScript

Fable is a compiler for F# to JavaScript.

It brings all the good parts of functional-first programming in F# to JavaScript development.

Even without a lot of knowledge of Node.js and the JavaScript ecosystem, it is fairly easy to get started with and use functional-first programming for client-side browser applications. Fable can also be used for client-server, Node, mobile or desktop applications.

After reading the very nice introductory tutorial Getting started with Fable and Webpack I was ready to make an implementation of SameGame.

It is integrated in this post and you can play it right here in the browser.

This sample was also published on Fable’s official sample site where you can find more information on the implementation details.

Continue reading →

How F# can help with the pitfalls of C# enumerations

I don’t get it. Even in a statically typed language like C# you can change the domain model and your application will still compile as if nothing happened. In this post we will address this and see how F# can help with such pitfalls of C# enumerations.

What’s the problem?

The problem with enumerations is simply that when we add new cases especially in a large code base, it can be really hard to find and update all dependent source code which might lead to errors at runtime.

The compiler will not help to find all the places that have to be updated. A text-based search isn’t reliable.

Here is how things can go wrong.

Continue reading →

Domain Design, data- or function-centric?

There are two great articles by Scott Wlaschin on how functional programming can be used for the domain design of real-world applications by implementing a Tic-Tac-Toe game. He demonstrates how business rules can be modeled with types, how data hiding, encapsulation, logging and capability-based security can be achieved with functional programming and more.

What I found remarkable is that in the second article he completely re-engineered the first design. Even though to me the original implementation appeared to be very appealing.

I liked that the data-centric domain model was concise, totally clear and very close to the natural notion of the game. Eventually it couldn’t meet high security standards since there were ways for malicious users of the API to manipulate the data.

The second function-centric implementation introduced the concept of capability-based security. The design smells of the previous version could be resolved. But I argue that the API of the second version is not as intuitive as the first one anymore. Technically it is also quite simple. However, the recursive structure doesn’t come totally natural to me. Also an indicator that the second version is more complex is that logging becomes trickier.
Continue reading →