Kotlin

Contract Tests are examples that describe the behaviour of an abstraction by expressing what cannot be encoded in the type system. These are typically helpful in testing adapters as defined in the Ports & Adapters architecture.

This time, we’re going to refactor our solution towards an object-oriented (OOP) style. The finite state machine we implemented previously enables us to take advantage of polymorphic behaviour while sticking to immutability.

In event sourcing, the state is derived from events that have happened in the past. In a classic approach, state is persisted while events are lost. In an event-sourced system, it’s the events that are persisted while state is derived.

Let’s implement the Mastermind game with event sourcing. For now, we’re only focusing on the domain model.

Let’s consider how functional domain model might work in practice by applying the event sourcing pattern.

A functional domain model is made of pure functions and immutable types. As Domain Driven Design teaches us, it should be expressed in the language shared by everyone involved in the project.