This is the fifth and final part of this series. In this last part we’ll reduce the boilerplate code related to handling events and as a bonus we’ll also make handling validation a bit nicer. But before we take a deep dive into the code, let’s consider the design of the last three Invoice implementations.
Continue reading Towards an immutable domain model – monads (part 5)
We’re already on the fourth part of this series. In this part we’ll explore how we can improve on the original design now that the invoice is immutable.
Continue reading Towards an immutable domain model – believe the type (part 4)
In part 1 we looked at a stereotypical implementation of an
Invoice domain class. In part 2 we introduced event sourcing to extract the durability and reporting concerns from the behavioral requirements and to move closer to making the
Invoice immutable. In this part we’ll explore the first implementation of an immutable
Continue reading Towards an immutable domain model – immutability achieved (part 3)
In the first part of this series an
Invoice domain object was defined as a starting point for discussing immutable domain objects. JPA and Scala were used for the example implementation. In this part we’ll look at this example from a different perspective to move closer to an immutable domain model.
Continue reading Towards an immutable domain model – immutable change (part 2)
This is the first part of a (short) series of blogs on implementing a rich domain model using only immutable domain objects. This first part introduces a (simple) example domain model and provides a JPA implementation using Scala. This exampe will serve as a baseline that should be familiar to most developers who have experience with an ORM. The other parts of this series will redesign the example to use only immutable objects and will explore some of the benefits and drawbacks of doing so.
Continue reading Towards an immutable domain model – introduction (part 1)