I just finished reading Domain Driven Design: tackling complexity in the heart of software by Eric Evans. This is a book that was recommended to me years ago but I was lazy and ignored the advice - and what good advice it was.
Hopefully you are familiar with the concept of a domain model. Implementing a domain model is by far my preferred technique for dealing with business rules in software, probably because so much of it leverages the strengths of object oriented programming (and don't get me started about how much I love OO). The thing about domain models however, is that getting one up and running is only half the battle. I am big fan of the Martin Fowler book Patterns of Enterprise Application Architecture and much of it deals with accomplishing this task. But the thing is, there are already plenty of object-relational mappers avaliable, both commercial and free. Given this fact, its probably incorrect of me to refer to technical aspects of using a domain model as "half the battle" as it should make up a far smaller proportion. The real battle is putting a domain model to work, leveraging its strengths and guarding against anaemia. Designing a domain model of true value is no easy task and it is this particular problem that Evans focuses on in DDD.
I really enjoyed the first half of this book, being the two sections Putting the domain model to work and The building blocks of a model driven design as I found then easy to follow and very relevant to the work I am doing. Some of the concepts described were familiar and worth reinforcement, but several were completely new. The second half of the book consists of the sections Refactoring towards deeper insight and Strategic design. I found these sections a bit more uneven than the first, and particularly dry in places. Ever caught yourself and realised that your eyes scanned the last half a page without any of it actually sinking in? This happened to me more than a few times, but I think its as much my own fault as it is Eric's. Putting aside these complaints, the second half of the book is still a very worthwhile read as it introduces many valuable concepts.
Its probably worth mentioning that there is not a great deal of code in this book as it is much more concerned with theory than with the hands-on practicalities of developing with a domain model. I can recall a few instances where the book describes a mechanism that made a lot of sense, but it was not entirely clear how I would actually go about implementing it. I am considering picking up a copy of Applying Domain-Driven Design and Patterns by Jimmy Nilsson in the hope it might help fill in some of the gaps.
It occurs to me that there might have been a better way to approach the topic of DDD and it might have made Evans a bit more $$. If you take the first two sections of the book and add a few choice selections from the remaining half, you've got an excellent text for introducing developers to domain modelling. You could hand a developer that wasn't experienced with using domain models a 200 page text and they would come back in a few days excited and with a firm knowledge foundation. The majority of the second half of the book consists of material that is more relevant to a developer in a leading or mentoring role and this would easily fit in a follow up, "advanced" book.
But don't let my theories on how the material might have been better packaged distract you, because DDD is still a really good book. A few years ago, when I was reading CLR via C# by Jeffrey Richter, I felt kind of embarrassed that I had been doing all this .NET development without much of a clue of what was going on. Reading DDD made me feel much the same way about building applications that use domain models.
Generalizing the design of data products
10 hours ago
Great review of a great book Paul.
ReplyDeleteDDD strikes me as "Get people other than the actual programmers to understand O-O". I suppose it must be something more. What your one-line summary?
ReplyDeleteThat is, your one-line summary of "DDD minus OO".
ReplyDeleteHey Andrew, thats a pretty good question.
ReplyDeleteFirst of all, I don't consider DDD to be about "getting non
programmers to understand object oriented design". The relevant
audience for this book is programmers/architects, and MAYBE business analysts if
they are heavily involved in the modelling process.
I would say that some of the concepts the book discusses could be described
as "specialised OO", and could be discovered naturally by trying to apply good OO design to a particular problem. However the book also discusses plenty of concepts that map more closely to system design than to object oriented design. For example, the question of what to do if you have separate teams working on the same overall system - how can you effectively share the model or portions of it? What boundaries can you define to make the process easier? What do you do if two teams have developed separate models in isolation and it becomes necessary to merge or connect them? These sorts of problems don't really fall into the realm of OO design, and much of the latter half of the book discusses this sort of problem.
I think you could pull out examples in the book that simply make sense from a good OO design perspective, some other examples that don't really relate to OO, and a few more that are somewhere inbetween.
Ok so I didn't actually give you a one line summary of DDD minus OO.
ReplyDeleteHow about:
"Common, useful patterns to apply when designing a domain model, from the basic design of object interfaces to managing large-scale structure."
Malcolm, care to weigh in on this? I didn't find this easy, and I'm not particularly satisfied with my answer.
(p.s. for the benefit of anyone else reading these comments, it was Malcolm that originally advised me to read this book)
It's difficult to describe in a one-liner as OO and DDD are not orthogonal concerns. I would suggest that the easiest way to desribe it would be that OO is concerned with classes, interfaces, inheritance etc. and their relationships, while DDD is concerned with OO patterns that can be used to develop a domain model such as specifications, services, repositories, value objects, aggregates and responsibilities. You can't simply say 'DDD minus OO' as DDD is built on OO, any more than you can talk about C# without talking about OO.
ReplyDeleteI should clarify something. I didn't mean non-programmers are meant to read the book. I meant that DDD involves non-programmers modelling their problems in an O-O like way. But out with the old.
ReplyDeleteThe new: Based on your responses I'll change my one line summary to: "Think about all the aspects of your problem, not just the individual pieces of software, in an O-O-like way." Here I am thinking of "specifications, services, repositories, value objects, aggregates and responsibilities" as things that naturally arise from thinking in an O-O-like way.
Andrew,
ReplyDeleteI kind of like your one liner and think it's pretty appropriate. I would question the second part of your post though - if you think that patterns as complex as specification and repository arise 'naturally' from OO then more power to you! Mere mortals like me however still benefit from the documentation and description of these patterns - Evans taught me an awful lot.
Andrew, where did you become familiar with the patterns that you listed? Because you pretty much gave a quick rundown of the topics covered in the first half of the book. I agree with Malcolm, deriving those patterns naturally from OO is a pretty big ask.
ReplyDeleteI'm not familiar with all of them. That list was cut-and-pasted from Malcolm's post.
ReplyDeleteI'm not too sure about "deriving" them from O-O per se. But I would say that, when trying to "find the classes" before the coding commences, abstractions like, say, Specification, do naturally arise.
My view is that books like Design Patterns exist precisely because the abstractions therein naturally arise so frequently that it's worthwhile to pre-learn them so that they can be spotted more quickly, and implemented more effectively.
Andrew, somehow I missed one of Malcolm's comments, now I follow.
ReplyDeleteThis book *IS* a pattern book, but with a more specific problem domain.
"My view is that books like Design Patterns exist precisely because the abstractions therein naturally arise so frequently that it's worthwhile to pre-learn them so that they can be spotted more quickly, and implemented more effectively."
ReplyDeleteI couldn't agree more with you on this Andrew, but I think there's also a bit more to it.
I believe that the less abstract the concept, the simpler it is to learn and subsequently recognise. Some patterns are so obvious that they tend to emerge naturally. For example, I used decorators and what is now called the 'dependency-injection pattern' long before I had heard either term, simply because they were the most logical way of solving the problem at hand.
As the level of abstraction rises however the gap between the implementation and the abstraction, naturally, increases. In simple terms this creates a lot more scope for things to go (or be done) wrong.
A good example is the mapper and unit of work patterns as per the Fowler model. When developing a data driven application, it is logical to deduce that I will need some classes to return some data in the form of objects and that I will need some way of tracking change and submitting those changes back to the data store. The problem is that this requirement is so abstract that there's many, many different (and often appalling) ways of implementing it. In a long-winded way, this brings me back to DDD. Books like DDD and PEAA deal with the specifics of highly abstract patterns - that is they offer an (or more than one) implementation as well as providing a narrative that discusses the pros and cons of alternative approaches.
Basically, what I'm saying is that 'pattern' books about highly refined patterns (such as Design Patterns) very much are about being "spotting more quickly, and implementing more effectively,", books about more abstract patterns (unless they are useless) tend to focus far less on the spotting and far more on implementation.
Good point.
ReplyDeleteWonderful explanation Malcolm.
ReplyDeleteThat's a nice review, Paul. The implementation of DDD is something which I still struggle with, however. I've played around with a few OR/M tools such as doodas and most recently LINQ.
ReplyDeleteThe concept of persistence and scope of the unit-of-work is not easily implemented especially in a non-persistent medium such as web pages. Proper implementation of theories is extremely difficult, especially from someone who little experience in that area.
And yes, I wholeheartedly agree with this:
"As the level of abstraction rises however the gap between the implementation and the abstraction, naturally, increases. In simple terms this creates a lot more scope for things to go (or be done) wrong. "