You don't need to read all the patterns in the DDD book

You are not meant to read all patterns in a design patterns book. Read the introduction, browse through the patterns in the list - usually at the back of the front cover, Note a few that spark your interest, and read those.

I need to remind myself regularly of this, so this short post is as much for me, as it is for you.

I’ve met many people who somewhat sheepishly say:

I haven’t read the entire Domain Driven Design book.

And I think that’s okay. In fact, I think your meant not to read the whole book. The book, like all patterns books, is a collection of design patterns.

Design Patterns are a solution for a problem in a context.

If you’re not in the right context, that matches the pattern and you don’t have the problem, then you don’t need the pattern.

So I think the best way to read a patterns book is:

• Maybe read the introduction to see what it’s about, and why it was written.
• Browse through a few patterns.
• Then go back to the list of patterns in the beginning of the book with a brief description.
• See if any of these patterns match a problem that you have.
• Read the pattern and read the context and the problem carefully.
• If that matches, then you might try out the solutions
• After trying it, see if it works for you.

And if it doesn’t work for you, that’s okay.

It’s a pattern. It’s something that someone found useful in a couple of matches for the context and problem there. But if it’s not a good match, that means your problem is slightly different. You learn something about your problem.

Software development often has two outcomes: working software and learning. Sometimes you learned that the pattern actually wasn’t a good match for your problem and that’s fine.

You revert, iterate, and continue.