CODEWITHSUNDEEP
eventsdomain-driven-designversioningcqrs
nesh_s
nesh_s

Reputation: 399

Event versioning in CQRS

We are at a point in our development cycle (asp.net mvc applciation), where we need to introduce changes to our existing commands and events (say adding/removing a few properties etc).

I have been trying to find a way to introduce commands/events versioning in the system. I have read many posts on google/stackoverflow etc but am still to see an example of code that implements it. Is there a recommended pattern one should follow when versioning. If yes any examples/snippets?

Edit: This is how far i have gotten with this

  1. i have versioned my events backwards, such that the latest will always be called the same, while the ones that go obsolete will have a suffix added to it like '_V1', '_V2' etc.

So if i have an event 

public class OrderSubmittedEvent : IDomainEvent
{
    public int OrderId { get; private set; }

    public OrderSubmittedEvent(int orderId)
    {
        OrderId = orderId;
    }
}

and if i have to add a few properties i rename my event above to 

public class OrderSubmittedEvent_V1 : IDomainEvent
{
    public int OrderId { get; private set; }

    public OrderSubmittedEvent_V1(int orderId)
    {
        OrderId = orderId;
    }
}

and introduce another event with the same name as my original event but with added properties, like so 

public class OrderSubmittedEvent : IDomainEvent
{
    public int OrderId { get; private set; }

    public OrderSubmittedEvent(int version = 1, int orderId = 0, string customerName =  
                               "Joe blogs", string address = "Earth")
    {
        OrderId = orderId;
        CustomerName = customerName;
        Address = address;
        CurrentVersion = version;
    }

    public static int LatestVersion
    {
        get { return 2; }
    }

    public int CurrentVersion { get; set; }

    public string CustomerName { get; set; }
    public string Address { get; set; }
}

i still have to go ahead and change my code which publishes this event to include values for new properties.

  1. any given point of time when i get all my events from the event store (say, for replaying) they will always be of the same type after deserialization (in this case OrderSubmittedEvent) with new properties which were not part of the old events populated with their default values.

At the time of replaying my events i make my events go through an IEventUpgrader This first verifies if the events is the latest version available. since the type will always be the event type, this check is based on the properties "LatestVersion" and "CurrentVersion"

what does everyone think of this approach?

next todo

  1. If event is an old version publish an 'UpdateMYEVENT' Event

thanks

Upvotes: 5

Views: 5211

Answers (5)

Val
Val

Reputation: 539

I would be cautious with mixing events and commands. They have different purposes and solve different problems.

To give a better feeling of what I mean, think of it like so Commands are more like RESTful API, client-server communication. While Event Sourcing is more of a way to store the data.

Both need versioning as a way to provide backward compatibility through immutability, but once again for different reasons. Hence implementation and exceptions are different.

I would definitely recommend a book Event Versioning by Greg Young to get more insides into versioning for event sourced systems..

I've also tried to gather some thoughts around Events and Events Evolution, Versioning and Migration.

For more information on the commanding, check out the CQRS series and particularly CQRS via HTTP.

Upvotes: 2

Waku-2
Waku-2

Reputation: 1196

I am totally out of reasons while considering why would one need event-versioning the way it has been asked in question and more specifically the way it has been suggested in the answers?

I can think of only two use cases

1- the event class currently being used is deprecated and no more needed. Then that class can be tracked down in the git anytime needed. So why bother and complicate the active code by keeping the dead classes?

2- The business requirement is changed and now you need to keep the base event but you also need another similar event with some parameter differences. That can be solved in a number of ways, like decorator pattern can help to handle such variations to a great extent Alternately the new event might be representing a unique domain concept and instead of trying to force the concept into existing model, it might be better to name it more semantically and use it that way.

Upvotes: 1

Eben Roux
Eben Roux

Reputation: 13256

Admittedly I have not had the opportunity to try the following but I'd like go bake in the versioning from day one:

Since the full type name is relevant I would go for namespaces.

namespace Primary.Messages.V1
{
    public class CompanyCreated
    {
        public Guid Id { get; set; }
        public string Name { get; set; }
    }
}

namespace Primary.Messages.V2
{
    public class CompanyCreated
    {
        public Guid Id { get; set; }
        public string Name { get; set; }
        public string TaxNumber { get; set; }
    }
}

These could be in different assemblies and you could mark the older ones as obsolete (as suggested by Sarmaad). It may be that older version are not necessarily obsolete though.

Any ideas?

Upvotes: 2

Tom
Tom

Reputation: 511

If you are only adding & removing properties, there might be no need to version events; just ignore the serialized properties that are removed, and use sensible defaults for the ones you add.

Upvotes: 5

Sarmaad
Sarmaad

Reputation: 426

usually you only need to version the events, you can ignore the commands since you don't store them in the event store.

There are few ways to implement versioning.. my method is quite simple:

[Obsolete]
public class CompanyCreated
{
    public Guid Id { get; set; }
    public string Name { get; set; }
}

public class CompanyCreated_V2
{
    public Guid Id { get; set; }
    public string CompanyName { get; set; }
    public string TaxNumber { get; set; }
}

You need to handle conversion of events from the old one to the new one as you read the events from the event store.

also, you need to be aware that you never remove any old event classes, hence why I decorate them as Obsolete, to let other developers know not to use the event.

Upvotes: 8

Related Questions