Although I was on vacation for a week, I found the time to read Applying Domain Driven Design and Patterns by Jimmy Nilsson. I would highly recommend this book, but I would recommend that before you buy it, you go out and purchase and then read Patterns of Enterprise Application Architecture by Martin Fowler and Domain-Driven Design by Eric Evans (they are worth your hard earned money). There are a lot of concepts presented in Applying Domain Driven Design that are talked about in these books.

Having said that, the first section of the book Jimmy introduces you to topics such as Test Driven Development, Refactoring and Design patterns and how they aid the Domain Driven Design process. Personally, no matter how many times I read these topics, they are some of my favorites in software development and I will always re-read them when I see them in a book to get a different perspective on them.

I particularly enjoyed the sections on techniques for Querying, and different approaches to object relational mapping. Jimmy talks about the Identity Map, Unit of Work and Lazy/Eager Load patterns and the pros and cons of each patterns (Jimmy does a good job throughout the book distinguishing pros and cons of the different patterns).

After Jimmy has talked about ORM in an abstract way. He shows you how to practically use NHibernate. This chapter was a good introduction to NHibernate for me. Although being in the middle of the ocean and not having a computer to try it out was kind of painful.

Chapter 10 is almost entirely written by guest authors and introduces some design techniques. There are some good articles on Inversion of Control/Dependency Injection, Service Orientation and Aspect Orientation. After reading this chapter I would like to try and experiment a bit with Spring.net and some of the other IoC containers.

Conclusion

Jimmy does a good job in teaching about how to focus on the domain model while developing an application without worrying about the infrastructure of your app until the right time while teaching numerous domain driven concepts. I can see myself constantly coming back to this book in the future.

As Jimmy puts it in the epilogue the book is structured in a Domain Driven Designish way:

1. First we try and collect the requirements and understand the problem.
2. Next think about the approach to use when structuring the main logic (this may not even require a domain model).
3. We need a certain style for the domain model, not only to avoid common traps, but also to create something really powerful. Try and settle the Ubiquitous Language.
4. Think about the required infrastructure.
5. Think about how to deal with presentation.