25% Off New York September Class
(if Booked this Month)
- Sept 27, New York, DDD Overview
$690  $510 if booked by 7/31
- Sept 28, New York, DDD Immersion
$2790  $2090 if booked by 7/31
Course descriptions, registration and more dates here »
Or call us at: (+1) 914 482 1273
Does New York seem a little daunting?
New York can seem a little overwhelming, but it can be fun too. Our classes are small and personal. Give us a call, and we can provide advice on hotels, dining, navigating the subway, and whatever else you might need.
Report on DDD Exchange 2010
by Eric Evans
The second annual DDD eXchange in London is done. Wow! It turned out even better than last year.
The idea had been to make this a real conference, where experts convened to confer on the issues and questions of the moment in DDD. And that is what happened! I am really proud of the outcome.
Rather than cram the day with talks which, while potentially informative, put attendees in a passive position, we focused on two broad themes: Architectural Innovation (especially Event Sourcing and CQRS) and Process Integration (combining DDD with Agile, TDD, BDD, etc.). We also included a lot of opportunities for interaction between everyone present. The whole was greater than the sum of the parts.
DDD is all about the fundamentals. As such, it doesn't have the continual buzz of new versions and releases every few months. DDDers continue to explore models in a creative collaboration between domain experts and software experts. They strive to cultivate a ubiquitous language within a bounded context and use it to write expressive code. An increasing number of practioners have begun applying Strategic Design to position their projects for success. These fundamentals continue. Yet the means of doing them evolves.
In 2010 the community's attention is turned toward two areas of innovative energy: A family of architectural approaches that promise to scale DDD more effectively and more clearly mark context boundaries; and a new look at fitting DDD and Agile processes together along with a handful of other key best practices.
Defining DDD - And where do I fit in?
I kicked the day with a talk called "Define DDD." It endevored to define DDD and the essential terminology of DDD. Why? There are two reasons. First, in order for a school of thought to thrive, a balance must be struck between two tretcherous poles. On the one side, the field may be too open. Everything comes to be called DDD. The term means anything and therefore nothing. This would lead to very wide adoption of the term DDD, but the value would be lost. (For example, I fear this has happened to some extent with SOA.) Tipping in the other direction leads to DDD being to narrowly defined, or so tightly controlled by a few individuals, that innovation is stifled and a closed community grows stale and shrinks into irrelevance.
What we need is simple clarity about what DDD is, so that DDD isn't everything, yet it is broad enough for innovation. Also, we need to define terms within DDD so that we can discuss alternate approaches clearly. It is easier to define what is essential to DDD now than it was 6 years ago, in part because so many people have attempted innovation in ways that challenged the definitions as written in my book. I'm happy to say that while a few of the specific recommendations from the book turned out to be a bit too narrow, the fundamental concepts and patterns are holding up well. The work of others has helped clarify and deepen my own thinking about DDD.
Today there are a number of experts who know some particular approach to DDD better than I do (such as the other speakers at DDDx). It is gratifying to me to have a community of peers to explore with and learn from.
So, in my opening talk I set out to define DDD in a way that balanced those concerns, and to clarify some essential terms that have often been muddled. You can see my presentation from the conference here.
As I explained in my talk, there is just one priviledge I would like to hold on to: being the final arbiter in the definition of the basic DDD terms. There is no need for a final arbiter of the best way of doing DDD. In fact, it is healthy to have competing approaches to getting things done. However, if we are to have an intelligible debate about alternate approaches - the pros and cons, the range of applicability - then we must be able to explain to each other what those approaches are in a language we all share . So having a single definition of key terms is the sort of uniformity that actually facilitates free innovation. You may like a particular use of domain events or you may dislike that use, but for you to even make that point we need to agree on the definition of domain event. (In fact, you can see examples of healthy disagreement and debate in the park-bench discussions at DDDx.)
DDD Themes for 2010: Architectural Innovation & Process Integration
After my talk, Udi Dahan talked about CQRS and Greg Young talked about Event Sourcing, and then we had our first Park Bench discussion, which was focused on those two topics. I think people were surprised to hear Udi and Greg (and me too) digging into points of disagreement about how an event-oriented system should be architected. I was not. It was just the sort of fruitful debate I was hoping for from the event. That first park bench is well worth watching. It can be viewed online here.
I first became aware of Greg Young in preparing for the DDD track at QCon San Francisco 2007. He described a software system that processed tens of thousands of financial transactions per second with demanding latency requirements. The conventional wisdom was that in this regime you could not afford object models and abstractions. Yet, Greg's team had not gone down to the metal. In fact, they had increased the use of abstraction, creating a more complete object model than most projects by modeling every state change explicitly as a distinct object.
Event Sourcing, as it has come to be called, is an architecture that extends DDD into the realm of high transaction volume and is one of the hottest topics in DDD right now. In event sourcing, every state change must be represented explicitly as an event.
This was the key that allowed them to scale. Entities do not hold state that is modified. Instead, they compute their state on request, based on the accumulation of state changing events. This means, among other things, that data is only inserted into the system, never modified.
This architecture also increased the use of publish/subscribe messaging. In this way a transaction could be processed without any responsibility for updating state - and without the associated processing overhead and contention. Instead, any new activity in the system (such as a trade) was represented as an event and published. Any entity whose state might be affected (say, an order book) would be subscribed to that event. In some cases, consequences might be computed and republished as new events. In other cases, the affect of the event need not be computed until someone asked for it, which in some systems is far less frequent than updates.
Furthermore, this made it far easier for them to keep reporting and other consumers of their information loosely coupled. Context boundaries were clearer, and translation of messages was easier than in other forms of integration.
Now, nothing here was truly new (and many of you know how suspicious I am of the truly new); yet, it was fit together in a clean and simple way that allowed a level of performance and scaling I had hithertoo ceded to the necessity of low-level, obscure optimization. And that would have been enough to make this an important innovation, but it also coincided with another area of increasing interest in DDD.
A domain event is an explicit, discrete representation of something that happened in the domain. Explicit domain events and clarify many domain models. Like any good pattern, they were used before the pattern was written, but a shared name and documented description clarifies its use. (Just take a look at my awkward categorization of the "Handling Events" on page 167 of my book. Groan.) The domain event pattern had been documented in the community even before I wrote my book. When I saw that early version of Event Sourcing, it became clear to me that it belonged in the set of DDD Building Blocks, along with Entities, Value Objects, and the others. (See my writeup in the March issue). Domain Events are abstractions, parts of many a successful domain model for many years. Greg's architecture turned the dial up all the way, and showed the possibilities that opened. Event sourcing has been a strong influence on my own designs in recent years.
Watch Greg's talk here.
Read Gojko Adzic's excellent live-blogging of this talk here.
I haven't known Udi Dahan for so long. He has emerged as a leader in the DDD community and has formulated an architectural principle he dubbed Command Query Responsibility Separation (CQRS). (Frankly, I hope they come up with a better term at some point. However, by any other name it is still having an impact.)
Once again, something old is being used in a new way with important implications. An old software engineering principle is that operations should either update state or behave as functions, returning an answer to a query without causing any side effects, but not both. CQRS extends this to entire subsystems, so that state enters through a dedicated subsystem that has no query responsibilities at all, while all queries are handled by subsystems that, while drawing on that state, are entirely side-effect free. Udi's contention is these two aspects of a system are so different that combining them into a single subsystem leads to cumbersome designs and all sorts of scaling problems.
Personally, speaking as one DDD practitioner, I am still unsure about just where and how I would choose to apply CQRS (although I am clear they should choose a new name!) There are certainly some fine points to be worked out. (For example, how often are the query and command systems in separate bounded contexts? This question was debated, without resolution, in the park-bench discussions.) It is clear, though, that it is a promising innovation in DDD - the sort of thing I hoped for six years ago.
I'd also recommend Udi's interesting talk at DDDx (not specific to CQRS, though clearly coming from that perspective) common pitfalls in applying DDD .
Does This DDD Stuff Work in the Real World?
Next up was Ian Cooper, with an experience report about the use of DDD over the last 18 months at Beazley, a large insurance company. (They do underwriting for Lloyd's, for example.)
Experience reports are important. The evidence of what actually works and does not work lies in the results on real projects. Ian described what they did and some of the things that went well as well as some of the things that did not. He shared his insights on the keys to those good outcomes. And a great thing about an experience report is, you can decide for yourself if you agree with his conclusions, yet still gain from the experiences he relates. Video here.
TDD, BDD, Agile - Oh, my!
The final segment of the day was focused on development process. Gojko Adzic started it off with a talk about how he has brought together DDD, TDD, and BDD, improving collaboration with the business people and clarity around design changes. Watch it here.
My talk in this segment was about how DDD and Agile fold together and what happens on Agile projects that neglect design. This is a topic I'll write about in an upcoming issue of this newsletter.
Register Early for Next Year
Pizza and beer were on hand for the final park bench. Discussion roved over all the topics of the day, but it was clear that people were most urgently interested in the ins and outs of Event Sourcing and its kin.
This was one of the best events I've been to. DDD is not a static, finished thing. The DDD Exchange gave us a forum in which to see the directions people were going and explore and debate issues of how to advance the state of the art.
I'd encourage you to sign up early for DDD Exchange 2011 next June. They tell me it is already 20% full! More here.