| |
|
I am the author of Domain-Driven Design, (Addison-Wesley 2004). That book was based on 12 years of experience modeling and designing large business systems. Now I focus on making projects more valuable and agile by effective use of design.
I’ve come to my current specialty by a winding path; several threads converged to give me a viewpoint that couldn’t have been planned. Of course, I can fit it all neatly together now, through hindsight.
Back in 1984, I had just finished my Bachelor’s in Math and Physics, and I was burnt out. I decided to go knock around South America for a while. After half a year I had had enough knocking around. I was reinvigorated, so I returned and took my first brief plunge into the financial world.
I went to work for the Kansas City Board of Trade and simultaneously did futures market analysis. I designed and wrote a set of software routines for this research that could be combined to test a wide variety of trading systems. This was the first time I wrote software that needed to reflect a domain in a supple way. But I was not a technologist. I was a market analyst.
I got restless and decided I wanted to take a more technical direction. I went back to school for a Master’s in chemical engineering. My research was in mathematical models of chemical reaction kinetics, and to prove the models, I had to write software that could numerically solve them. This software did not need flexibility, but the models themselves were distilled to a simple clarity that made them powerful and versatile.
This was the period, in 1987, when I stumbled upon Smalltalk. I was immediately hooked, although it would be some time before I saw an opportunity to pursue object-oriented programming professionally. I completed the Master’s in 1989 and went to work for a few years in semiconductor manufacturing technology. But by then I knew my first love was software development.
My chance came in 1992, when the first surge of interest in object technology hit Wall Street. I started doing outsource Smalltalk programming in New York, then joined a Smalltalk development project in an investment bank as a lead developer. This project had a solid design culture, iterative development, continuous integration, automated builds, and on-site customers. Our results were very good. At the time, I did not realize how rare the properties of that project were.
I moved from New York to the San Francisco Bay Area in 1995, lured by the Silicon Valley hot-bed of technology and also by my budding passion for windsurfing. Since settling here, I’ve worked both locally and nationally on Java and Smalltalk projects in several fields, including finance, shipping, insurance, and manufacturing automation.
These experiences have converged from different angles to give me an unusual perspective on how models can be refined and used.
Objects became mainstream in the late 1990s. That larger world was more dynamic, but it lost, for a time, some of the design culture of the early object community. Too often, those who were serious about design and modeling squeezed the life out of the process with elaborate diagrams in complicated tools and boring documents. Design patterns emerged as one hope to raise the level of design, but those hopes were never fully realized.
Then Extreme Programming (XP) landed, reemphasizing rapid iteration and more fluid and direct interaction with domain experts and other "customers". I dived in, joining a series of projects attempting XP. I was a programmer. I was a coach. I was a trainer. I worked with the purest XP and with various hybrids. These experiences convinced me that the Agile processes were essential to bringing the creativity back into software development, not to mention the fun. But something else was missing.
In a reaction against the kind of modeling and design approaches that had paralyzed projects for several years, some of the most aggressive advocates of Agile process had become publicly skeptical of the very idea of modeling and design. This combined with the disappointment of many non-technical people, who had been promised miracles would come from all that analysis modeling and were inclined to "just make it work". For a few years, design seemed to become almost a dirty word. During this same period there was wide adoption of heavy frameworks like J2EE. Some of these environments made it so hard to just get something to run, that they overwhelmed subtle design efforts.
Yet throughout the 1990s and 2000s, a few projects produced software that fulfills the promise of objects. I decided to write a book to try to share the ways a small but successful group of people worked. This was a community I was a part of, and we were not always conscious of the practices embedded in our design culture. I spent 2001, 2002 and 2003 trying to organize it, develop a language for it, and express the way of thinking underlying it. That is how I came to write Domain-Driven Design.
Now I am focused on making sure my consulting clients get their money’s worth from their software development efforts by focusing on their core domain, effectively expressing that model in their software, and instituting a process that makes business experts and software experts effective collaborators.
A software project should be a voyage of discovery that a team of software experts, domain experts and business strategists all take together. A team like that can collaborate to chart a course to a very valuable destination that is not entirely known at the outset. Not only do I think software development should be creative and fun, I assert that that is essential to getting the most business value from a development effort. To produce great software designs requires a greater degree of experimentation, even playfulness, with design and language than usually occurs. It also takes disciplined, skilled programmers committed to making their model of the domain take shape in the heart of the software.
Eric can be reached at 415-902-7873 or eric @ domainlanguage.com .
