Ddd

Last week I shared my theoretical understanding of event sourcing. Today, I want to make an attempt at making that theory tangible by implementing an event sourced aggregate. In traditional systems, we only persist the current state of an object. In event sourced systems, we don’t persist the current state of an object, but the sequence of events that caused the object to be in the current state. If we want an aggregate to be event sourced, it should be able to rebuild itself from a stream of events, and it should be able to record all the events it raises. ...

I’ve been studying event sourcing from a distance for little over a year now; reading online material and going through some of the excellent OS code. Unfortunately, there would be no value introducing it into my current project - it would even be a terrible idea, so I decided to satisfy my inquisitiveness by consolidating and sharing my understanding of the concept. Domain events An event is something that happened in the past. ...

Working on side projects, I often find myself using RavenDB for storage and IronMQ for queueing. I wrote about that last one before here and here. One project I’m working on right now makes use of domain events. As an example, I’ll use the usual suspect: the BookingConfirmed event. When a booking has been confirmed, I want to notify my customer by sending him an email. I want to avoid that persisting a booking fails because an eventhandler throws - the mail server is unavailable. I also don’t want that an eventhandler executes an operation that can’t be rolled back - sending out an email - without first making sure the booking was persisted succesfully. If an eventhandler fails, I want to give it the opportunity to fix what’s wrong and retry. ...

A good while ago, I blogged on commands (and queries). After exploring various flavors, I eventually settled on this one; commands, handlers and an in-memory bus that serves as a command executor. Commands help you in supporting the ubiquitous language by explicitly capturing user intent at the boundaries of your system - think use cases. You can look at them as messages that are being sent to your domain. In this regard, they also serve as a layer over your domain - decoupling the inside from the outside, allowing you to gradually introduce concepts on the inside, without breaking the outside. The command executor gives you a nice pipeline you can take advantage of to centralize security, performance metrics, logging, session management and so on. ...

Hanging around in the pub after DDDX, I ended up talking to Alberto Brandolini. For those who have never met him; he’s very much into visualization. You will always see him carrying a drawing pad, with a dash of permanent marker on his cheek, and a few lost sticky notes on his back. I don’t know if it was the Italian accent and the strong gestures, or my mildly intoxicated condition, but the idea of visualization as an important tool grew on me even more that evening. ...

This post is a follow-up to my previous blog post “Accidental entities - you don’t need that identity”. In that post, we followed a consultant building an application for a car rental. One of the requirements was that the CEO could manage a collection of available colors. Although the tools at our disposal - a relational database and NHibernate - wanted to trick us into making a car reference one of these available colors by its identifier, we found out that the CEO really thinks of a car’s color as a value, and does not care about a color’s identity. This means that we didn’t make a car reference an available color, but we copied its value instead. This allows the CEO to remove available colors, without it having an impact on cars that already came in that color. ...

An entity is identified by an identifier, while value objects are identified by their value. If I make a living renting cars to tourists, I might not care the least about the identity of the colors the cars came in. I just care about their value; Rosso Corsa, Azurro Metallic… If I repaint the car, the color changes, and the previous color is abandoned as a whole. However, if I were a car paint manufacturer, I would care a great deal about the identity of a color. My first action might be to make up a marketable name for the color, something that I can identify it with - a la Burnt Sienna or Iceberg Blue. The color might have a certain structure from the get-go, but I might experiment with the structure along the way, while I’m still referring to it as the same color. ...

This is the second and last part of my notes I scribbled down attending the IDDD Tour. The first part was published last week. A better model Even if you come up with a better model, the fact that it has been the ubiquitous language of the domain for decades proves that it works for them. This quote bothers me a bit. There definitely is truth to this, but modeling an existing process often presents such a great opportunity to revise and improve it. Naked models don’t conceal deficiencies, inefficiencies and aberrations. Exploring alternative models free of habituation, politics and legacy is dirt cheap, while the outcome could considerably benefit all. It seems such a shame not to take advantage of this. As with most things, know when to pick your fights. ...

Two weeks ago I got to spend four days attending the IDDD Tour by Vaughn Vernon. Although my book queue has only allowed me to shallowly browse the book, I had high hopes for this course. I anticipated a week of getting lectured on DDD with a few practical exercises, but was blown away by the openness and interaction promoted by Vaughn and his associate Alberto Brandolini. A passionate group, engaging workshops, long days and lots of sharing made these few days exceptionally satisfying and inspirational. I’m grateful to those who got this show on the road; it was more than worth your trouble. ...