Introduction

I've been lining up a list of books to read and going through them slowly. I'm not exactly sure how this all came together, but a great place to start is by Listening to what Martin Fowler has to say about software design.

I got his book Patters of Enterprise Application Architecture (Look at more books by Martin Fowler here) and got a couple of hundred pages into it. At that point, he had already referenced DDD and Eric Evans enough times that I decided to take a break from his book and go pick up Eric Evan's Domain Driven Design. This is pretty much the bible on DDD, and a great way to get all the details right from the horse's mouth.

You'll find many a blogger/consultancy/online-course that talks about DDD and how to employ it in specific contexts, and that is all great, but reading this book is a solid foundation to get started down that road.

My thought on the book

The book starts off very high level and introduces the concepts that will be explored throughout the book. I feel like the first few chapters were very light reading, that gets me comfortable with subject matter and gives me an overview of what the book wants to accomplish, which is great. Gets me engaged and doesn't scare me off with a lot of technical jargon.

Then once it starts going into more detail, it immediately hits close to home, because all the problems it tries to solve are problems I have already struggled with multiple times on various software projects:

• Fighting coupling in code
• Defining clear interfaces between the various parts of the code
• Deciding where the business logic should live
• Figuring out how to manage tests in a way that doesn't couple itself to infrastructure
• Finding the seams between services, APIs, and infrastructure and structuring it so it doesn't bog down the project

The latter half of the book is a bit more in-depth, and I'll admit it lost me a couple of times. It goes into a lot of detail about what we want to achieve by employing the subjects, but doesn't provide a very hands-on toolbox for applying the concepts. What is missing for me is a walkthrough of how to change the culture of an establisehd team to start embracing DDD and how to get started small. And even though I'm not exactly a fan of "ceremony" like all of the "process artifacts" that things like SCRUM bring to the table; it would be good to have a few ceremonies of process that would help set the direction for the cultural shift.

On social media, I hear about Design Thinking, Event Storming, etc. which is not necessarily birthed out of DDD originally, but it seems to play very well together. So maybe that's a point to explore next.

And if all else fails, there are plenty on consultants ready to jump in and educate our team. That may be money well spent as well 😉

Closing comments

Although it would be nice to be spoon-fed all the answers, which this book does not, it definitely covers a lot of important subjects, and it helps by providing a vocabulary and a way of looking at Software Design that invites a lot of thinking and conversation, that I can bring to my team.

Definitely a recommended read. I follow the sentiment in the preface of the book, that this is a must-read for any software developer