cameronfletcher.com

random thoughts and discussions on the things that interest me

Event Sourcing Presentation

I gave a presentation recently on event sourcing. The talk included a demonstration of a system that I had been involved in designing and implementing that made use of events as a mechanism for storage.

The content of the presentation was heavily influenced by Grey Young’s QCon talk “Events are not just for Notifications” hosted on InfoQ here - in some places to the point of verbatim – so if you are interested in the message I was trying to convey I suggest you watch his video. For those that attended my course the slides and notes for my presentation can be found here: eventsourcing.pptx

I was surprised by the interest in the topic especially from some senior architects. It would appear there is a growing recognition that there is an inherent reduction in complexity when you’re forced to think of the boundaries that are implicitly enforced when moving to a distributed architecture.

As the reaction to the talk was good I shall be giving a follow up talk in September – this time on the subject of CQRS.

CQRS and when the Penny Dropped

I’ve been working on a project for a while now where the requirement is to provide a more scalable and better performing version of an existing system.

We chose to base the new system on Greg Young’s open-source SimpleCQRS project. Earlier this week I was refactoring one of the domain objects when I came across something like the following:

private string description;

public string Description
{
    get { return this.description; }
}

public void ChangeDesciption(string description)
{
    ApplyChange(new DescriptionChanged { Description = description });
}

private void Apply(DescriptionChanged @event)
{
    this.description = @event.Description;
}

I noted that the public Description property was unused, so I removed it.

Then the penny dropped.

I noticed that I could remove the private description property too because it was not used in any of the business logic. Then the previous sixteen lines of code became the following four:

public void ChangeDesciption(string description)
{
    ApplyChange(new DescriptionChanged { Description = description });
}

Less code. More sense. And a growing realisation that I had been confusing the responsibility of the GUI to display the description of the product with that of the domain object which was only concerned with business logic – something that the product description had nothing to do with.