DDDx, short for Domain Driven Design Exchange, is a one-day event dedicated to Domain Driven Design. Held once a year in London, it has a program packed with talks from the leading thinkers and practitioners in DDD, who share their latest ideas, experiences and insights.
At Edument, we have a great deal of interest in DDD. It's been a focus of both myself and Carl Mäsak ever since we've been working here, and we were happy to be sent along to DDDx to hear new ideas, get inspired and - most importantly for Edument - use what we learned to enrich our mentoring and our classes.
So, off to London we went. This being England, it was of course raining when we arrived. Happily, that didn't dampen our enjoyment of the evening before DDDx, which we spent focusing on a couple of domains that are of some importance to both of us: Indian cuisine and microbrews. London, happily, lived up to expectations in both regards. A good night's sleep, a tube journey, a walk where we only got a tiny bit lost and some coffee later, we had taken our seats and were ready for the sessions to begin!
I've long been a multi-paradigm guy. Objects are important and their role in modern software development is significant, but I've never seen them as the one true way. Thus, I was very excited that the opening talk at this year's DDDx was about applying DDD through functional programming.
In it, Greg Young - best known for CQRS and Event Sourcing - revealed that really, event sourcing is functional programming. This was a sudden, "oh! yes!" moment for me. Event sourcing has always somehow felt right at a gut level. I've never really cared for the "you get an audit log" arguments in favor of it; I mean, that's nice, but not always a requirement. The thing I really cared for was the way you could write tests: given these events from the past, when this command happens, then the consequence is this.
It's blindingly obvious in hindsight, but the reason an event sourced system is easy to test is because business logic becomes pure - in the functional sense. Testing pure things is just about always far easier than stateful things.
Additionally, all of the various operations involved in event sourcing are now easily expressable as functional ideas. Obtaining the current state is just a fold. Taking snapshots is just memoization. An event store is really just a functional database, with the latest event just cons'd onto the existing event list.
With all this in mind, my take away message is that there should be a far better way to factor command handlers than I have been doing to date. Most probably, the command handler should return events. Well, it's something to play with.
Next up was Dan Haywood, speaking on RESTful objects. REST APIs have become increasingly popular, and it's interesting to consider how they fit in with domain models. At first, it may seem like they are in conflict. DDD highly values building models that capture intent, which means looking at the verbs. By contrast, RESTful systems are focused around just a few verbs (such as the HTTP GET, POST, PUT and DELETE). Thankfully, though, a few important insights make the situation a lot better. Previously, I've learned much from Jim Webber on this topic; Dan Haywood had some additional and different perpsectives that were also good to hear in this session.
The mapping of a domain model to REST is not to simply expose the domain objects themselves. It is to expose resources, which in turn capture the current application state. (Some of those domain objects may be good as resources anyway; it's just not an ideal starting assumption. Dan pointed out that a big consideration here is if the API clients are under your control or not.) Links embedded in the resources specify the operations that can be performed next. And - here was one of the big takeaways for me - this is where your intentful operations are conveyed. The "rel" - or relationship - attribute in HTML is a standard way to convey the intent of the state transition that will take place by following the link. The Restful Objects Specification provides a standard for doing similar but with JSON.
Once again, hypermedia is what it's all about. It's one of the more subtle parts of REST, and probably the most overlooked. Without it, though, it's probably meaningless to call a system RESTful.
Alberto Brandolini gave the final talk before lunch, and it was packed full of great insights and ideas. It's easy to think being an architect is about making decisions, but really it's about finding opportunities to put off decisions. Why? Because at the start of the project is the worst possible time to decide anything. Alberto showed a graph of ignorance against time, noting that during a project you start off largely ignorant of the problem at hand, and this ignorance decreases over time. Often there is a moment of clarity that causes a big drop-off. Therefore, it's later on in the project that decisions should be made - when there is a good basis for making them. Seen this way, software development really becomes more about learning and less about building. I really liked this viewpoint, and want to find ways to reflect it more in my own work.
The talk moved on to consider the domain modeling process. Again, there were plenty of insights on tricky matters. I was happy to hear Alberto's positive experiences on modeling in terms of events, and hunting for the aggregates afterwards. Finding the right aggregates is a hard problem. Events are rather easier to start identifying for domain experts, who are far more used to talking about processes. Events lead the way to the commands that produce them - and only then is it really sensible to look at the data and how it is split up into aggregates. Essentially, the aggregates are determined by grouping the behaviors.
This is a very different approach from the database driven development that happens in so many projects today, where the focus is on the data, not the process. This leads to systems that are all about editing. But, as Alberto pointed out, "users are not hackers". It's easy for developers to look at a bunch of pieces and say, "well, I can make this process out of these pieces by using them in a certain way". Users typically are not like that, and don't think in that way. It would seem that domain modeling starting from events plays an important role in developing systems that offer a good user experience also - something that is not immediately obvious.
Lunch time came along, and after a fascinating morning of talks, it was nice to have a little time to mull it all over. The talks so far had all embodied what attracts me to DDD. None of them focused on implementation reality to the detriment of modeling, and none of them focused on modeling to the deteriment of implementation reality. Refreshing, inspiring stuff.
This post is quite long enough by now, but stay tuned for part 2, where I'll discuss what I learned from the afternoon sessions at DDDx 2012!