Reflections on 2010 and What the New Year May Hold
Happy New Year, fellow DDDers!
A new technical landscape is opening, and DDD is being adapted and enriched. As many others have pointed out, the combination of several technological changes (e.g. cloud computing, mobile devices) is bringing a big shift in how software is deployed and used. This is the most exciting time since the web explosion of the 1990s, and I won’t even try to predict the direction software development will take. I will make some observations about recent trends and the opportunities I see for DDD.
The trends of distribution of services and apps on the web continued or accelerated in 2010, further fueling interest in CQRS and Event Sourcing. These have been hot topics in DDD for the last three years. The formerly obscure Domain Events pattern has taken center stage and elegant new ways of modeling domains have been hammered out by those working in that area. Although wide-spread adoption takes time, CQRS and Event Sourcing are taking their place as understood architectural options for DDD, along-side the traditional layered/hexagonal.
A new trend, still in the vague early phases, is the rise of interest in functional programming in main stream application development. DDD grew up in the object-oriented (OO) world, and so the patterns were tailored for that platform in particular, the building-block patterns. Is OO particularly well suited to DDD, or was this an accident of history? The functional paradigm has never been widely used in business applications, yet that may be changing now. DDDers who are venturing into this area are thinking about which of the patterns are useful, and how these patterns might be reinterpreted to take advantage of the particular strengths of the paradigm. I’ve speculated in the past that functional programming would be a good foundation for DDD. We are about to find out! In the process we may gain insights that sharpen and distill the patterns themselves, feeding back into the way we apply the patterns in OO design. For my own part, I’m experimenting with Clojure. I’ll write more about this in the newsletter later this year.
There is more, of course — notably, mobile devices. They are an almost untouched realm for DDD. In the past, they did not have sufficient support for programming abstraction to support DDD. Now they have crossed a threshold both in wide adoption and in surplus processing power and have the abstract programming platforms to go with it. Time to explore!
Tools Matter
There is one recent trend I perceive that I deeply hope continues: For the last few years we’ve seen new tools and architectural styles that are less complicated and loosely coupled that the previous cycle.
This trend is illustrated, I think, by Git, the humble source code control tool. In the 1990s, server-based tools such as Clearcase got more and more complex and unwieldy. CVS maintained its hold as the simplest viable alternative. Subversion eventually came along as a cleaned up CVS, a conservative upgrade that was a conformist in context mapping terms. Now comes Git, a clean break. Git is as simple as CVS, and it has a clear model with a ubiquitous language. Subversion, as a conformist to CVS, inherited its predecessor’s tight coupling to the central server. Git makes no assumption that there even is a central server. The user can interact with distinct repositories and define relationships between them.
Tools matter. Although DDDers subordinate the tools to the domain goals, we benefit from good tools. In particular, we benefit from tools that put power in our hands to work efficiently while taking up a minimum of our precious mental capacity, freeing up more of that for thinking about domain scenarios and our models. The source code manager is a little thing, but there are a lot of little things, and they add up. In the late 1990s, there was a wave of complicated tooling and frameworks (e.g. early J2EE) that presented a serious obstacle to DDD by swamping us with technical complexity. The swamp seems to be draining a bit.
Here’s to 2011!
Eric
[Note: This article was originally published in the Domain Language Newsletter, January 2011.]
