Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
Great "answer", it is more up for discussion what should be consider the answer to my question but your thoughts in the subject were really good. –  Tomas Jansson Dec 12 '11 at 20:03
add comment

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.

share|improve this answer
    
I agree. The notion that you can grow an architecture from the ground up based solely on the writing of unit tests is a false premise; this premise is what makes TDD so confusing to outsiders. –  Robert Harvey Nov 29 '11 at 16:38
    
Yet growing the architecture with tests is the very idea at the foundation of TDD. If it makes things confusing, it's because it questions basic assumptions. These basic assumption (that we should decide on architecture and frameworks before coding) is one that deserves a whole lot of questioning, IMHO. –  xpmatteo Dec 9 '11 at 15:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.