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.
A collaboration test is an example of interactions between the subject of the test and its collaborators often replaced with test doubles. A contract test confirms assumptions made in test doubles.
A function is one of the smallest units of behaviour. Functions can be composed to build coarser behaviours. What granularity and altitude to test behaviours on?