CQRS DDD Entity Framework Infi

Event Sourcing NerdDinner – Coding Dojo

0 Comment

We had an Event Sourcing coding dojo at Infi this Tuesday. Turnout was 18 people, half of them being Infi employees, the others enthusiastic community members. The dojo was a big success: we had a lot of fun, learned new stuff, met new people and had a great discussion afterwards. I’m really happy about this 🙂

For this dojo we prepared a custom version of NerdDinner, the canonical ASP.NET MVC example app, so it could act as a playground for experimenting with event sourcing. To support event sourcing we made these modifications:

  • Added basic infrastructure for raising events (the Event, Event<T>, IEventData and EventScope types)
  • Load events when hydrating a Dinner entity (DinnerRepository.Find)
  • Added DbSet<Event> to the NerdDinners DbContext to add a table for storing Events to disk
  • Have a hook for the NerdDinners DbContext intercepting published Events (NerdDinners.OnEventsPublished)
  • Removed mocking from the unit tests so that you could run the tests against the DB
  • Implemented RSVPing using Event Sourcing (RSVPController.Register)

All event handling is done synchronously, so you don’t have to bother with eventual consistency and all that stuff, instead you can just focus on the core event sourcing concepts. Also, the result is actually a hybrid mutable state / ES solution, since there’s still some data stored in table rows. We didn’t feel it was worth the effort to completely move to event sourcing for this dojo, though it might be a fun exercise. You can have a look at the code on github. Please note that this infrastructure is not production-ready nor production-tested, so keep that in mind if you want to base your own infra on this code.

The exercises

With the above code available at the start of the dojo, we set up a couple of exercises for pairs to tackle during the evening.

Spoiler alert: the following description of the exercises might contain partial answers to the exercises; if you want to do the dojo please consider doing that first.

1. Cancel your RSVP

With RSVPing already in place, canceling is the next logical step. In this exercise you can explore how event sourcing works in the RSVP case, and try to apply that to canceling. It ends up being more or less a copy-paste exercise, but one that lets you quickly explore the various steps involved.

2. Show a dinner activity feed

In the dinners details screen we’d like to show an activity history, with entries for RSVPs, cancelled RSVPs, location changes, etc. This is very easy to implement using event sourcing, but hard using mutable state based persistence. In fact, in the latter case you probably end up persisting event-like things. The goal of the exercise is to show how event sourcing helps you do useful stuff that is otherwise hard to implement.

3. Change the address for a Dinner

In the original application, updating details for the dinner was very CRUD-y. You would have one form in which all details could be edited and then saved. This approach doesn’t work particularly well with event sourcing since you’d usually want the events to express more intent than just “Dinner Changed”. To do so, you usually build a task-based UI, with explicit commands for certain (domain) operations. In this exercise that domain operation was changing the address of the Dinner (in hindsight the operation maybe should’ve been called ChangeVenue). The goal was showing how using event sourcing might end up requiring changes to the UI.

4. Optimize the popular dinners query

The NerdDinner UI has a list of popular dinners:

popular-dinners

It’s a list of dinners sorted by RSVP count descending. Producing this list efficiently with event sourcing is harder than in a mutable state based scenario, because we don’t have the current state readily available to query on. Since we now need to sort globally on all dinners, we would have to fetch all dinners and events and then do the sort entirely in memory. That could become a problem if we have a lot of dinners in our system.

So in this exercise the goal was to listen to the RSVPed and RSVPCanceled events and build a separate read model for keeping the count of RSVPs per dinner, and use that to sort the list. We expected this exercise to take most time, but a few pairs managed to finish the exercise within the allotted time (about 2.5 hours for all exercises).

Please do try this at home!

All in all, I think doing the above exercises could be a good introduction to event sourcing, and most of the people that attended agreed.

So, if you want to try out event sourcing at your company or just want to experiment with it yourself, doing this dojo might be a great way to start. Just clone the code and try doing the exercises (all exercises have accompanying tests to get you started). Please let me know about your results 🙂

Object-oriented Philosophy

Liskov substitution principle is not for objects

0 Comment

The Liskov substitution principle (LSP, the L in SOLID) relates a type and its subtypes using the following definition:

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

Which is often interpreted as “at any point in a program where I use an object of type T, I can safely use an object of type S”. In this context, safely means the program can use S without it crashing or causing otherwise undesirable behavior. This interpretation, however, is less stringent than Liskov’s definition, which says: “the behavior of P is unchanged when o1 is substituted for o2”. A behaviorially unchanged program to me means there’s no functional difference, or no difference in output/side-effects (this does allow for differences in space/time requirements).

To give an example of objects that do conform to LSP, let’s look at an abstract data type (ADT), such as a set or a stack. Obviously, there are many ways of implementing a set. However, from the point of view of a program using a set, it shouldn’t matter which implementation you use for the program to behave correctly. If the set implementation attains this property, it has conformed to LSP.

When doing OOP, however, changing the behavior of the program is often exactly what you want. Take the ubiquitous UI Widget class hierarchy example. In this case, you subclass a base Widget in order to get the information specific to your application onto the screen. Here, different behavior for the program using the Widget classes is the entire goal of this design. This means though, that with regard to LSP, the subclass is not a subtype of the base Widget, nor should it be. The subtle point here is that there’s a difference between subtypes and subclasses. A subtype is defined by LSP, but it says nothing about sublasses. However, when talking about LSP in SOLID, LSP is often explained in terms of subclasses instead of subtypes, and this is wrong as this example illustrates (unless you think the design is actually bad).

LSP, therefore, is not a general principle to live by when doing OOP. In fact, a lot of programs/designs are useful exactly because they violate it. OOP is much more powerful than just implementing ADTs, and we shouldn’t apply constraints that hold for ADTs onto objects. That being said, you should make sure that you don’t violate any implicit or explicit assumptions made by the clients of the base class, which I assume is the underlying reason LSP made it into the SOLID principles at all.

Credits

I already had these concerns when first reading about LSP a couple of years ago, however I only thought about writing a blog post about it when I watched a presentation by Kevlin Henney (at around 33:00) a couple of weeks ago where he talked about the same subject. Also, my thinking on objects vs ADTs is influenced greatly by “On Data Abstraction, Revisited” by William Cook and “The power of interoperability: Why objects are inevitably” by Jonathan Aldrich, both are excellent reads if you are interested in OOP theory.

Uncategorized

New design

0 Comment

Hi all,

I updated the blog with a new design. The old one was just the default wordpress theme, and I thought it would be nice to have something a little bit more custom. I personally like big fonts when reading blogs, so that’s what I went for. If you have any feedback, please let me know 🙂

Cheers,

-Freek

Testing

Using syntax highlighting to improve the readability of your tests

0 Comment

One thing I obsessively focus on is test readability. The reason being that it’s often very hard to understand what a test is really about; usually the signal-to-noise ratio in tests is very low, and that makes it hard to understand what is being tested. So I continuously try to improve the readability of my tests by experimenting with different styles. Yesterday I was working with my colleague Sander, and we discovered yet another trick that I think can help: syntax highlighting.

Consider this piece of code:
nohighlighting
It tests for certain SEO properties (the contents of the robots meta tag in the HTML) based on the current status of the specific page.

Now, I think these tests already have a relatively high signal-to-noise ratio. The thing is at a pretty high level of abstraction, and you can probably follow what’s going on as non-technical person. It is, however, less clear what the difference are between these two tests. In fact, only 8 characters are different, out of a total 312 characters. It’s really hard to spot what those differences are when you start reading this code.

Now consider this form:

withhighlighting

While the number of changed characters is exactly the same, I think both the original intent and the differences between the tests are way more clear. When I get back to this code, my eyes will immediately be drawn to the strings, which happen to also capture the essence of the tests, which is what we’re after.

Book thoughts

Book thoughts: Hackers and Painters

0 Comment

Hackers_&_PaintersI finished reading Hackers and Painters: Big ideas from the Computer Age by Paul Graham the other day. This book was suggested to me by Henk Jan Pluim (very nice guy), and I really enjoyed reading it. It’s nice short book, with very strong opinions about pretty much anything, including politics, popularity, economics, statistics and, of course, programming.

For me, one of the most interesting parts of the book is that the author asserts that one of the key competitive advantages when running Viaweb was that they were programming in Lisp. He goes even further, by stating that “Lisp is the most powerful language available”.  The argument goes that it’s a fact that some languages are more powerful than others (due to the fact that they vary in abstractness: c is more powerful than asm), but you can only see that another language is less powerful when you actually know the more powerful language. At the top of the chain is Lisp, since apparently its macros let you do things that are extremely powerful, yet not any other language contains a feature that is at all comparable.

Now I’m not entirely sure if that reasoning is entirely sound: the whole point of language wars is comparing your language to another language and arguing the other language is less powerful due to it missing certain features. I currently take the position that in business (web) apps, you can probably solve similar problems in the same amount of effort and with the same amount of elegance in C#/F#/Ruby/Python/Scala/PHP/Java/Go/Clojure or any of the other currently popular high level languages for that kind of work. Nonetheless, I don’t want to dismiss the idea that there can be unknown unknowns that might significantly shift my thinking. Maybe Lisp-style macros is one of them, so I’ll definitely put in some effort to learn more about them.