I learned all about logical design of relational databases back in school; tables, columns, data types, views, normalization, constraints, primary keys, foreign keys… At the same time, I learned how to use SQL to put data in, and how to get it out again; INSERT INTO, SELECT, FROM, WHERE, JOIN, GROUP... In the first project I worked on just out of school, we weren’t doing anything interesting with databases; we didn’t have that many users, or that much data. A database veteran on the team took it on him to maintain the schema and to provide stored procedures we could do work with. ...

Last night, I returned from Vilnius, after seven intensive days of Buildstuff. After a few long months, I was looking forward to be influenced and inspired by concepts and experiences strange to my day-to-day job - surrounded by people hungry to build better software. Because of the diversity of the program, the high level of the speakers and the presence of some familiar DDD-community faces, my expectations were easily met. Also, the location and low rates for tickets, transport and beer make it a very reasonable investment. ...

When things are fragile, they break easily. We often see fragility as a bad thing and design things to be robust. But this isn’t what we’re really after either; things that are robust might be hard to break, but they’re also hard to change, making them fail to adapt to new stressors over time. The model that we’re really after is antifragility; when something is antifragile it will benefit from stressors and get better over time. ...

I heard a story once about an engineer who worked on the Disneyland site when it opened in Anaheim, CA in 1955. A month before the park opened, the new grass and sod were being applied to the grounds as one of the last items to be completed before the big grand opening. The parking lot was some distance from the park’s gates and required a lot of turf. However, the sidewalks had not been planned or constructed to accommodate patterns. ...

At Euricom, we quarterly all retreat to headquarters for a day of sharing and learning. This time, I and others organized and facilitated an event storming workshop. After a short introduction on event storming participants were initiated to the domain of Cambio CarSharing - which is packed with behaviour. After that, seven groups of five (+ one domain expert) spread out across the office, and spent two slots of twenty minutes modeling the domain - with two extra slots for feedback. ...

Like I mentioned last week - after only five posts on the subject - there still are a great deal of event sourcing nuances left to be discovered. My current event store implementation only supports a single user. Due to an aggressive file lock, concurrently accessing an aggregate will throw an exception. Can we allow multiple users to write to and read from an event stream? Also, what can we do about users making changes to the same aggregate; can we somehow detect conflicts and avoid changes to be committed? ...

Having covered projections last week, I think I have come full circle in these posts that turned out to be a small preliminary series on event sourcing. Even though there are still a vast amount of nuances to discover, I think I’ve captured the gist of it. Even without running an event sourced system in production - I feel as if I somewhat have an idea of what event sourcing can bring to the table. ...

In my first two posts on event sourcing, I implemented an event sourced aggregate from scratch. After being able to have an aggregate record and play events, I looked at persisting them in an event store. Logically, the next question is: how do I query my aggregates, how do I get my state out? In traditional systems, write and read models are not separated, they are one and the same. Event sourced systems on the other hand have a write model - event streams, and a separate read model. The read model is built from events committed to the write model; events are projected into one or more read models. ...

Last week, I implemented an event sourced aggregate from scratch. There I learned, that there isn’t much to a naively implemented event sourced aggregate; it should be able to initialize itself from a stream of events, and it should be able to record all the events it raises. public interface IEventSourcedAggregate : IAggregate { void Initialize(EventStream eventStream); EventStream RecordedEvents(); } The question I want to answer today is: how do I persist those event sourced aggregates? ...

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. ...