Previously we spend some time preparing the code to support multiple kinds of events and data, rather than just supporting blog posts. In this part we’ll add user accounts, together with the required authentication and authorization code. We’ll again use event sourcing and the memory image to keep track of all users and currently active sessions. But the biggest changes to the application are related to security, and authorization in particular. It turns out event sourcing allows for an additional layer of authorization which allows us to whitelist any change a particular user is allowed to make.
Continue reading Simple event sourcing – users, authentication, authorization (part 6)
Recently I had to adapt some older Java code to support a new requirement: an existing CSV report needed to include a user’s email address, translated from the user id. Pretty simple, but how does the CSV report generator translate the user id to an email address?
Continue reading Picking the right abstraction
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)