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.
Getting 600 times better performance
11 hours ago