How do you end up with event-sourcing if you use a xDD approach?

Question

When working in a TDD or BDD manner your unit tests are supposed to drive your design. But how do you end up with event-sourcing using a xDD techniques? As I see it event sourcing is something you need to adopt early on to take full advantage of it.

Lets say that you start without event-sourcing and do a release. Later on when you are releasing version 2.0 you realize that it would be great to use event-sourcing, but at that point you alread have missed all the events from version 1.0 so it makes it much harder to implement. Or do you take some kind of backup of your db from before event-sourcing and use that as base line and then add event-sourcing on top of that?

Answer 1

Instead of thinking of Event Sourcing as being a purely design and technical issue, think of it as having a clear business benefit instead. For instance, if I'm using Martin Fowler's shipping example, I might have a business reason for wanting to know where a ship was on a given day.

It's possible that you don't have this business reason yet. Is there a possibility that you will have that reason, some time in the future? Some business requirements aren't just about the functionality you need now, but about keeping options open (almost the opposite of YAGNI). You can look at Chris Matts' work on Real Options to find out more.

Now that you have established the business benefit, think of TDD and BDD as helping you to establish which of those classes are responsible for that benefit. TDD and BDD don't help you to drive out good design as much as steer you away from the bad ones. They make you consider the responsibility of each of your classes, provide an example of how to use it thereby ensuring usable code, and ensure that each aspect of the class is genuinely valuable. You can still gain these benefits and come up with your own architectural requirements too.

Rather than trying to get architecture right, think about the cost of getting it wrong. Would it really be hard to adopt event sourcing later? If you discovered that the cost was prohibitive and the business didn't need it, how hard would it be to return to state-based persistence? As Chris has said in the past, if you don't know which technology is right, don't pick the right technology. Pick the one that's easy to change. It's either right already, or you'll have more information later that will help you to make better decisions. Your product owner or business expert may also be able to help decide whether the business benefit is worth paying for now.

Answer 2

Personally I think event sourcing comes in the category of 'architectural styles' - and it's never going to be easy to switch styles mid-project. That said it is possible (I've done it myself in the past). Here's a series of blog posts starting with this one that outlines one possible approach.

Both TDD and BDD are really 'requirements first' and generally you'll get enough requirements to have a feel for which architectural style is likely to be good fit. Getting this decision wrong can be very expensive - and without falling into the trap of 'big design up front' - this decision is one you'll want to spend some time over.

One a more practical level you can generate one or more initialising events from your existing data.