But I can't. Evans exhibits some combination of ignorance, lazyness and hubris in this book which I find enrages me to the extent of being disuaded from reading the thing in any depth. Very little, he states in the preamble, has been written about domain modelling. Well, that's true, compared to the amount that's been written about bullying web servers into doing something approximately useful, for instance. But more than none has been written about it, which is the impression you'd get from the (shamefully scant) bibliography, and the paucity of references in the body text. Where are the links to the work of James Odell, of Cook and Daniels, of Shlaer and Mellor, Cameron-Wills and DeSouza?
And the intellectual half-heartedness exists at the micro-level, too. There's a caption of Maxwell's equations used to illustrate the power of compressed notations to capture the essense of a domain. Well and good, but the 4 equation differential form is given and attributed to Maxwell, when that form of the equations was developed by Gibbs and Heavyside almost a decade after Maxwell published his twenty equations: the neat form had to wait for Heavyside to invent vector calculus, which Maxwell could not, and did not, use. That's just sloppy. A trivial point, you might think, but I find that this sort of thing lends an air of unreliablity to a whole work. Disappointing --KeithBraithwaite
I wonder. This book has been recommended to me by several smart folks out along the agile - OO vector. (Note my subtle heresy - not all along this vector are smart, and membership in this vector is not required for smartness.) So, I wonder if the appearance of such a book, whatever it's quality, isn't a good sign and inevitable. A good sign in that people with a paradigm in hand, everything "isA" object, (er - iteration, er - package, er - service, er - transaction, er - message, er - library, er - control structure, er - regular expression, er - list, er - state machine, er - data flow, er - form of discrete mathematics. Did I miss any?) Inevitable in that the paradigm du jour eventually crashes into ill-fitting realities, and people have to wake up.
When the new model that is easy to implement (because of the new tools) crashes into something it doesn't fit, then "analysis" reappears in whatever guise. Of course, from time to time people also run around declaring that implementation ability is now so powerful (or alternately, so consistently universally, indifferently medeocre) that understanding the problem domain is all that matters. Analysis uber-alles, vs. solution uber-alles. Neither is worth much by itself.
Delivering value through artifacts involves at least describing a problem, a synthesizing a candidate solution, and delivering that solution. We seem to rediscover in cycles that we need all three to do any good. I wonder if there is a book in that: "The Cycles of Technology" or some such, similar to TheCyclesOfAmericanHistory?. -- JamesBullock
Apologia:
Don't mind me. I'm grumpy today, dealing with some Java obscurity. Infinitely many libraries of twisty little features, an IDE that looks like a video game, and more MIPs than we could imagine back in the day. Still the problem boils down to an obscure misbehavior of some library either subtly misused or subtly changed. In any case, it ain't working, and the solution has nothing to do with the language, the analysis, the big tools or the paradigm. -- jb
The appearance of this book probably was inevitable. And having it is better than not. But it is still not nearly as good (especially given the plaudits it has recieved) as it should be. --KB
This reminds me of an observation from WhatDidYouSay: "Feedback is almost entirely about the speaker." The plaudits are probably saying something about the folks speaking, like maybe they haven't seen one of these technology / analysis cycles before. -- jb
That could be entirely correct. I am raving about the book and I haven't been in the software industry very long. --DaveHoover
To what class of person have you been raving about it?
To colleagues and customers, and on my [blog]. On my current project at DaimlerChrysler, DDD has provided me with the language to articulate some of the needs our customer is trying to convey. The [Bounded Context] pattern has been particularly helpful. -dh
Another reason that this book stands out is the complexity of the domains he uses for his examples. By looking at domains like cargo shipping and accountancy he prevents himself from giving easy answers to easy questions. This is not another book that tells you how to model the relationship between multiple owners and dogs or some other trite domain.
Evans believes you should have only one model. So the separate conceptual, specification and implementation perspectives suggested by the early editions of UmlDistilled (and which Fowler derived from the work of Cook & Daniels) are discarded in favour of a shared model that is used by all members of the project team. This model is meant to be isomorphic to the language spoken by all the people involved in the project. This ubiquitous language is meant to bind together the stakeholders, the developers and the analysts so that we can minimise difficulties caused by imprecise or implicit translations. Of course this doesn't mean that the customers must be made to understand the entirety of some massive UML diagram. Instead Evans accepts that you may have to translate for some of the project's stakeholders but insists that this is acceptable as long as the translation is explicit and/or temporary.
Evans advises us to separate this domain model from infrastructure and technical issues through layering. This like many of his ideas isn't original. However Evans has managed to organise them better than any comparable work. An excellent example of this is the Repository pattern. It is described in Fowler's PatternsOfEnterpriseApplicationArchitecture and in DomainDrivenDesign. In Fowler's book the focus is on implementation techniques but in this book we're shown the sorts of problems it solves, the consequences of choosing it and most importantly where it fits in the system of names/pattern language that Evans grows throughout the book. Even though I read PatternsOfEnterpriseApplicationArchitecture when it came out and have used the Repository pattern on production projects I found that Evans made me see it anew. Why? Because he shows the reader how that pattern can be combined with the notions of Aggregate, Entities and Aggregate Roots to tackle complex domains. Repository (in combination with Specification) goes from being a clever trick to hide your object-relational mapping choices to a fundamental technique that frees the development team to actually model the domain without worrying too much about their choice of a persistence strategy.
The techniques described will be most valuable on applications with complex domains and lengthy life-spans where ease of maintenance and evolution are extremely important. Most people building relatively simple web applications will probably find that the implementation focus of PatternsOfEnterpriseApplicationArchitecture will serve them better.
I've spoken to various people who have dismissed this book as 'just object orientation' and I believe that these people have missed something. This is a massive book (I had to force myself to maintain a schedule of 50 pages a day to get it finished) but it rewards detailed and complete reading. The first time I skimmed through it, reading only the sections that grabbed my attention I too dismissed it as nothing special. However when I went through it cover-to-cover I was able to appreciate the way in which Evans develops a language for thinking about complex application development which manages to exhibit internal consistency and coherency. The set of terms he uses may not be original but like the Gang Of Four he's given us a common language for discussing, using and building on these ideas. I fully expect to have more conversations in future where terms like Repository, Specification and Bounded Context will be used as naturally as developers use Singleton and Observer nowadays. But these conversations will include business analysts and customer representatives as well as developers.
This is not a book about objects but about modelling and managing domain entities. The numerous references to AnalysisPatterns? tells us something important about the breadth of the community that will benefit from imbibing these ideas. A non-technical business analyst will get as much, if not more, value from this than a developer precisely because it's about growing applications that reflect everybody's understanding of the domain rather than building OO codebases. As such the author doesn't waste much time talking about polymorphism, inheritance, etc because objects are only one way of expressing your domain. They may not even be the best way. Evans is willing to consider the prospect of performing DomainDrivenDesign using rules engines or even domain specific languages. Providing they give you a tangible benefit over OO.
Even though I believe or hope that in the long run this book will be as influential as DesignPatterns I suspect that its length and sophistication means it is more likely to suffer the fate of Arthur Riel's overlooked gem: ObjectOrientedDesignHeuristics. It is too long for most people to manage and demands that it's readers have a range of interests (from AnalysisPatterns? to primary key generation strategies) which is seldom seen in our ever more specialised industry.
There's a reason that there are fewer and fewer significant books about object oriented analysis are published nowadays. It's not because the likes of MeilirPageJones?, Cook & Daniels, Booch, Rumbaugh or Shlaer-Mellor have said all that needs to be said. It's just that it's a difficult area and most people find books like FundamentalsOfObjectOrientedDesignInUml?, AnalysisPatterns? or even newer work like StreamlinedModelling? to be deadly dull. And since very few people read Cook & Daniels or Shlaer-Mellor because they're 10 or more years old there are software development teams migrating to the wonderful world of OO who come to believe that the state of the art in object oriented analysis involves underlining the nouns in a requirements document.
This book is as important as DesignPatterns because it opens up the field of domain patterns where analysts/customers and developers can get together to 'crunch knowledge' (whatever that means) in order to define domain models that makes sense to both groups. This makes it clear that software development is a process of discovery (of knowledge about the domain as much as abstractions) which must be both iterative and include all stakeholders working out a common language they can all share. The insights Evans has collated form a bridge between these different groups and set the terms of debate about the future of domain analysis within software development projects.
DDD doesn't cover user stories so the requirements we're given tend to just appear out of nowhere but the use of a small set of sophisticated examples throughout the book gives Evans the opportunity to show that 'knowledge crunching' is an iterative process where later discoveries may invalidate earlier decisions. As we learn new things about the domain the code must be refactored to reflect this new and deeper insight. Domain Driven Design empowers agile teams precisely because the model it talks about is embodied in the code not just in diagrams and the language used in the model is shared by all the project's stakeholders. This means that a project that is delivering value on an incremental basis now has the analytical tools to adapt quickly since their domain model is clearly separated from the technical layers.
My main problem with this book is its length. It's very, very long. It introduces lots of new terminology and that can sometimes be overwhelming. The only thing I disagreed with in the 529 pages of DDD was the advice about using "import packageA.*" style statements as that leads to naming clashes and makes the code harder to understand.
The conclusion has that rarest of qualities in a software book: honesty. Like Gabriel in PatternsOfSoftware? he tells us about the projects he has worked on and has been using as examples. He describes mistakes made and makes a tantalising reference to performance problems with one of his projects that tried to follow a domain driven approach. As such it touched on one of my fears: what happens when these ideas are compromised? I have already seen some (rather confused) discussion on .Net related blogs as people tried to work through the practical consequences of this approach. What will happen when the people who never read books like this but prefer to hear pre-digested versions of it from other people stumble across these ideas? I can see some of these ideas being as damaging as some of the original design patterns precisely because they interlock so well that cherry-picking amongst them is likely to lead to incoherence and poorly performing projects. I suppose we shall just have to wait for the book that builds on Evans's insights but ties them even more closely to implementation issues about scalability and performance.
One to clear a shelf for. There's bound to be more where it came from.--AdewaleOshineye
. . . Not that you have an opinion.<g>
Well, with that endorsement it goes higher into my queue of "stuff that must get read." I'll reclassify this one from: "much trendiness that may contain a nugget" to "probably contains good stuff, wrapped in a trend and hype sandwich." Some of your gripes above (Adewale) resonate pretty strongly with me. For example, I recently read Paige-Jones FundamentalsOfObjectOrientedDesigninUML?, and rather than finding it "deadly dull", found it illuminating and useful - far more so than the deadly-dull swarm of implementation nit du jour stuff I have lately been grinding through in investigating the grand field of OO-ness.
At the risk of avoiding a good fight, my earlier rant had a lot more to do with the culture of gee-whiz or dissing than this particular book (which I have not read.) FWIW, the big, important books that say something that sticks show up from time to time, as I think is being demonstrated lately in software development. I'm enjoying watching the discovery of JerryWeinberg, and of TomGilb?'s PrinciplesOfSoftwareEngineeringManagement? all over again. Re-discovery for some of us. Not enjoying so much the grief I took the first time I mentioned these two sources in my early encounters with the Agile crowd. None of this has to do with the noise level when these books first arrive.
So, I'm suspicious of both hype and criticism, the louder the more so. When there's as much noise about a book as there is about this one I find the noise itself interesting but not an endorsement. If the book is any good there will be a constant, low rumbling about it more or less indefinitely. Or wait around for someone worth listening to, to make an impassioned case for the quality of the contents. If none of that happens, the trend-du-jour stuff is way cheaper to pick up once it's been remaindered.
-- JimBullock (I'm not cynical about lunch.)
I'm about to have a second go at this book; my first attempt a year or so ago was cut short either by my attention span, or how engaging this volume is.
The core appeared to be an instruction to use 'metaphor', or to make sure everyone uses the same langugage. Sound advice, and I hope that I can get some value from a second reading that I didn't get in the first. --ShaunSmith
![[Home]](/wiki.gif)