Posts

There are two big parts to Domain Driven Design; strategy and tactics. Strategy helps setting out a high-level grand design, while tactics enable us to execute on the strategy. Practicing strategic design, we generally first try to list all of the different parts that make our business a whole; these are sub-domains. When you look at a supermarket chain, you would find sub-domains like real estate management, advertising, suppliers, stock, sales, human resources, finance, security and so on. Sub-domains will often relate to existing structures like departments and functions. ...

Monday, I and four others did a DDDBE session on the strategic side of Domain Driven Design. My talk covered the Ubiquitous Language, and can be found on Slideshare. I might end up writing down the content of the talk as well - some images are meaningless without words. Evaluating feedback, I think the biggest mistake we made was keeping some things too abstract - curse of knowledge at work. If we get the chance to repeat the session, we need to make sure to weave a practical story through our talks to make them stick.

Over Christmas break, I set out three days to play with the EventStore. One of the things I wanted to do was visualize the timeline of a stream in the browser. Since the EventStore exposes its event streams over atom in JSON, I could directly consume them from JavaScript. An event stream can contain quite a few events. Since caching parts of that stream benefits all components in the system, the atom feed is split in multiple pages - where all full pages are cacheable. Thus if you want to read the entire event stream, you should work your way through all pages. What confused me at first, but what actually is quite logical, is that the last entry on the last page contains the first event. If you want to read the entire stream, you need to start at the last page, and work your way forward following the link to the previous page until there are no pages left to read. ...

We are surrounded by systems day in, day out. As software developers, we even get to spend a big portion of our day actively building and changing systems - be it software, teams, communities or businesses. Seeing the whole, but more importantly understanding how systems exist of inter-related parts that affect each other in all kinds of interesting ways, is crucial to growing sustainable systems. Thinking in Systems is a primer on the subject of system thinking written by Donella H. Meadows. The book is divided into three parts. The first part explains the basic concepts of system thinking using everyday systems. The second part covers why systems work so well, why they still surprise us, how to avoid common system traps and how to take advantage of some of the opportunities they present. The last part, and for me the most interesting part, shows where to intervene in a system and how to live in a world of systems. ...

In essence, repositories are a simple abstraction over aggregate storage. A repository will insert, update, delete or fetch an aggregate from the underlying persistence mechanism. This abstraction avoids that databases, SQL statements, Object Mappers and the like leak into your domain. Next to that, swapping out repositories for an in-memory version makes testing easier. Recently, the use of repositories is being questioned again. Why would we wrap Object Mappers in yet another abstraction? Aren’t Object Mappers already an implementation of the repository pattern? In a recent project, we left out repositories. In that project we’re using RavenDB, which already has an expressive API, and which can be configured to use an in-memory database for testing. Even though LINQ and indexes help make simple queries expressive, a lot of cruft still leaks in, not doing the language any justice. In other projects, we did make use of repositories over our ORM. Partly because setting up in-memory tests without was awkward at best, but also because it removed constraints trying to capture the language. Next to testing and expressiveness, you should also consider how comfortable you feel gluing everything to a library or framework. When it comes to aggregate storage, having those repositories is a small price to pay to keep technicalities out. ...

I normally write this up at the end of the year, but circumstances made me push back this post for a few weeks. I use this annual post to look back at the year passed, and to look ahead to the year to come. I gave up on making resolutions in 2011. This year, I’m going to be naively ambitious again going into 2014. Compared to previous years, I feel more confident that I have a pretty good idea of what I want next. Just before the holidays, my fiancée and I spent the weekend out of town where we took a whole evening to modelstorm 2013 and the future. We used green and red post-its to list all positive and negative memories of 2013. We then categorized those, and defined concrete actions to avoid repeating negative experiences, and to increase the number of positive ones in 2014. Next to this technique, we used a timeline to plan some key milestones a few years ahead of time. ...

Somewhere in the beginning of last century, two shoes salesmen were sent to Africa hoping to expand their employer’s market. Both salesmen reported home within days of their arrival. The first salesman wrote: “This trip turned out to be a waste of time; the locals are not wearing any shoes.” The second salesman wrote something similar, yet very different: “This is looking very promising; people aren’t wearing any shoes yet!” ...

Yesterday, I read this blog post by Michael Feathers. In the post he goes over a pain point he has often found himself struggling with while breaking down a large method; conditional statements. if (alarmEnabled) { var alarm = new Alarm(); ... alarm.Sound(); } Should we extract the if and the associated block into a new method, or just the content of the block? Is the condition too important to hide in a method? How would we name the extracted method? How do we avoid the code from telling us lies? ...

This time of year, we’re all very busy honoring traditions. This post is no exception (2009, 2010, 2011, 2012). Today was probably the first time this year that I took some time to study my blog’s Google Analytics metrics. If I keep last year’s black swan posts out of the equation, traffic seems to be comparable to last year’s. The most meaningful metrics to me are the number of subscriptions and the average time spent reading. Both of them increased - happy about that! ...

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