Spring as an enabling technology for applied Domain-Driven Design

I wrote earlier about the apparent embrace of Domain-Driven Design (DDD) within the Interface21 team, the group behind the excellent Spring framework for Java applications. I have been thinking about why it is that Spring in particular would lend itself to the application of DDD.

I first expressed this during the review of the DDD track last Wednesday for the start of the conference. The escape from the productivity hit we all took with Java EE when Spring first began to be known was a big deal. The ability to have an layered, n-tier application that was testable out of the application container, with the ability to wire up a bean container’s contents via a straightforward XML syntax breathed new life into many a tired J2EE web application. Lines and lines of tiresome boilerplate code for DAOs were replaced with clean, small implementations that extended the appropriate Spring template. The effectiveness of our domain models were about the furthest thing from our minds. Why didn’t we immediately address domain modeling as soon as we had our sea legs with Spring?

I would say it’s analogous to not being that concerned about what clothes you are wearing when you are starving to death. Remember Maslow’s hierarchy of need from basic psychology in college? Few people whose physiological and safety need are not being met care that much about self-actualization. There are enough shops using Spring for there to have been two consecutive conferences dedicated to the technology. Spring is ubiquitious; that was the thrust of Rod Johnson’s keynote today. It has proven itself as a productive, viable foundation of enterprise Java applications the world over. Given that foundation, there exists the capacity to ask, “how can we now move to the next level of applying Spring in the best manner possible?” Domain-driven design answers that question.

Domain-Driven Design is not easy, and many, if not most, technologies actually impede the application of DDD. This is where Spring stands out among the raft of framework options. It has always had the intent of staying out of one’s way rather than attempt to infuse all of your code with its own prescriptive dogma (insert JSR of choice here). Spring stays out of your way, enabling the necessary insulation of your domain model. Since it is also Open Source software, there’s no need to bolster a revenue model by implementing any such ugliness in an attempt to ensure vendor lock-in. The Interface21 group is freed of that burden throughy their choice of Open Source, they are freed to pursue excellence in the code unfettered by a need to drive sales of the software. Since they depend on revenues through services, they are driven to make the best framework possible that will be of sufficient utility for more people to need training and consultation they provide. The model seems quite sustainable, and I wish them the best.

A long-overdue break in the silence

It seems ages since I last wrote. There’ve been wisps of motivation here and there, but mostly from odd topics or observations. A few things have contributed to that.

My enthusiasm about software development ebbs and flows. At a visceral level, I love the craft. The creative aspects balanced with architectural principles can be fascinating, and are almost always challenging for any problem domain beyond the trivial. However, the forces that wish to subvert and pervert the craft into a means of capital gain sap my energy. At times it’s downright depressing.

It’s not that I am against earning money by developing software or helping others develop it; by no means. That’s certainly how I provide for my family. The thing that totally turns me off is the agenda of most vendors and a certain contingent of programmers to portray software development as a deterministic, engineering process that is easily commoditizable — if only you buy product X or employ heavyweight, tool-centric methodology Y. That lie has held sway over most of the industry for far too long, at the expense of the craft and all who participate in both the creation and use of software.

Another thing that has robbed me of enthusiasm for close to a year now was an emotionally demanding contract with a challenging client. I had to spend many hours dealing with the effects of the engineering/commoditization myths and the unrealistic expectations and unproductive results they yield on projects. Grinding against that kind of friction left me with precious little emotional energy, and I wasn’t willing to spend that on writing and leave my family with even more of a withdrawn shell of a husband/father.

There have been a few things lately that have been a refreshing/renewing force in my software development enthusiasm. The first has been the practice of Domain-Driven Design (DDD). The frank attitudes about the rigors of good software development that best serves the stakeholders with flexible, extendible systems is so refreshing. An acknowledgement of development as primarily a creative process and less significantly an engineering process is a welcome message for me. I have begun collaborating with Eric Evans, author of Domain-Driven Design: Tackling Complexity in the Heart of Software and the person who first crystallized the concept of DDD as a practice. It’s certainly been invigorating and I am being challenged to develop my domain modeling and design skills to higher levels.

The practice of DDD in and of itself is great, but enthusiasm for a practice without a community of fellow enthusiasts/practicioners falls mostly to the realm of wistful “shoulds” and “oughts”. I am starting to see others, practicioners of the craft whose perspective I respect, also warm to DDD. Their reasons seem sound; they aren’t attempting to accrete another buzzword to their repository. For some it even comes at the expense of having to point out flaws in their own past approaches (or those of their employers) to software development. It is my hope that their candor will be rewarded and not punished.

I write this from the hotel lobby of the Westin Diplomat in Hollywood, Florida. It is the day before The Spring Experience, which is the first conference I have seen with an entire track dedicated to DDD. Eric and I attended the DDD track get-together last night with the Interface21 guys, and I am greatly encourage to see how the Spring Framework project has embraced DDD. It seems a natural fit, but more on that in a separate post.