DDD: Relating Design Patterns to the Model

I am actually a bit surprised that this chapter is in the book. It did not even occurred to me that there might be a separation between design patterns and the patterns mentioned in this book. When I read the chapter that says that there is a close binding between the model and the implementation, I was already convinced that certain design patterns could be applied when modeling. After all, all of the design patterns are language agnostic so they are not tied down to implementation details. Also, we have already been looking at patterns from various patterns book, so I convinced that design patterns are high-level enough for domain modeling.

For instance, when the book talked about Aggregates and Repositories, I was under the impression that the Facade pattern might come in useful when we are modeling since Facade provides a higher-level interface that makes the subsystem easier to use. Or if my system will be relying on information from another system, I might use the Adapter or Proxy pattern between those two systems to make the two systems work together.

The chapter elaborates on why the connection pattern and the design pattern might be blurred. Some people have the notion that Design Patterns are technical hacks that one applies to overcome certain limitations in the programming language. Instead, I see them as general ways to think of how to design things. The technical details are important, of course, but the intent of the design pattern is even more important.

So, either I am completely off and the book is stating something very different. Or I am right in my assumption on how to apply design patterns and the book is merely stating the obvious.