Value object in event sourcing

Question

Is there a place for value objects in an event sourced domain model?

Lets define a value object as an object with immutable state that guards its invariants and has no particular identifier.

An event sourced domain model in this context is a domain that is entirely or partially event sourced, meaning that its current state can be derived from applying all events that have occurred in the past. Events themselves are considered immutable, even over time.

Debate has taken place about the validity of using value objects within events - this question goes slightly further: Do value objects have a place in event sourced domains at all?

The (potential) problem with using value objects is that it becomes rather tricky to alter the domain in such a way that invariants are tightened.

An example of this scenario would be to have a Username value object, with the sole constraint that the name must be anywhere between 2 and 16 characters.

While this has been working well for some time, the business decides to only allow usernames of at least 5 characters. A migration period begins and users with names of less than 5 characters are asked to update their names.

Lets say the process was successful, correction events are applied and everyone is happy. We tighten the constraints on our Username value object to require at least 5 characters.

For a while everyone is happy, but then we discover a problem with the snapshots and replay all events.

We now face an exception from our Username object: by loading the historic data, we're breaking an invariant of our domain.

The rules of a value objects apply retroactively - does this make them inherently unsuitable for event sourcing? Would it be worth applying versioning of value objects? Is there a simpler way of avoiding such problems?

Answer 1

I would say, that at the moment you redefined what Username means, and you don't migrate historical data somehow, you've essentially created 2 different Username meanings.

Because there are 2 different meanings of the word, you have to make it explicit in the code somehow. "Versioning" is one way, although I wouldn't use such a generic solution, there are different modeling options.

You could make it explicit that the history of a "username" is just that, a history. So for example create a HistoricUsername, which is the event-sourced object, even a value object if you want. And create a Username which is at all times the username with the most current rules, which is not persisted at all, but created from a HistoricUsername if it can.

Some people suggest sometimes to extract the "rules" from the object, and re-apply it later. That way the object itself is valid at all times and you can ask it to validate itself against rules that might change. I don't really prefer these kinds of solutions, but it's an option, and the Username would still be a value-object.

So the problem is not really that value-objects don't fit into event-sourcing, it's just that the modeling has to be more accurate.

Answer 2

We've solved this in a slightly different way. By separating the public API of our value objects from the internal (domain only) API, we are able to evolve one without affecting the other.

For example:

public class Username
{
    private readonly string value;

    // Domain-only (internal) constructor.
    // Does not enforce constriants and can only be called within the domain.
    internal Username(string value)
    {
        this.value = value;
    }

    // Public factory method.
    // Enforces business constraints. Used by consumers of the domain (application layer etc.)
    // to create new instances of the value object.
    public static Username Create(string value)
    {
        // Business constraints. These will evolve and grow over time.
        if (value == null)
        {
            // throw exception etc.
        }

        if (value.Length < 2)
        {
            // throw exception etc.
        }

        return new Username(value);
    }
}

Consumers of the domain must use the static Create method to create a new instance of the value object. This factory method contains all of our business constraints and prevents an instance being created in an invalid state.

Inside the domain, classes have access to the internal (constraint-less) constructor. Since this does not enforce any business constraints, an instance of the value object can always be created in this way (regardless of its value). By using this constructor when replaying events we can ensure that historical data will always succeed.

The benefits of this design are:

• A single class is used to represent the domain concept (no need for multiple classes, versioning etc.).
• Business rules are free to evolve over time.
• Historical data always works. A Username from a year ago is still a user name, even if our rules have changed.