Denver: Special Price for February Training
- February 1, Denver, Colorado, DDD Immersion
New York: A few spaces still open for March (or book early for June)
Course descriptions, registration and more dates here »
Or call us at: (+1) (914) 861-5264
Reflections on 2010 and what the New Year may hold
New Year Greetings from Eric Evans
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 accellerated 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 taylored 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 reinterpretted 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!
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 unweildy. CVS maintained its hold as the simplest viable alternative. Subversion eventually came along as a cleaned up CVS, a concervative 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.
Training the DDD Trainer
So much for the big world around us. For Domain Language, 2010 was the year when we established a regular schedule of public training courses in the United States. The DDD Immersion is now available every few months in New York and Denver with trainers I can unreservedly recommend. As you can imagine, it is a challenge to find and prepare an instructor for a class like the DDD Immersion. This class is not a long series of static lectures. It is a highly interactive workshop with a variety of activies devised to give attendees new insights into modeling and design and how to bring them to life in realistic situations.
Our preparation process has matured over the last couple of years and is intensive. Each candidate instructor co-teaches the course with me multiple times, with immediate feedback and mini-retrospecives in the evening after each day of the class. In between classes, we have exhaustive dry-runs of key presentations and exercises and long discussions that cover the topics raised in the course. Incidentally, the caliber of these instructor candidates is such that I never fail to gain new insights myself as we go through this intense process. Our instructors are not just teachers, they are doers.
The most recently certified instructor, Paul Rayner, who currently teaches the Denver classes and private classes, is one of the best yet. I can say with confidence that you'll have a valuable experience working with him.
Here's to 2011!