I have good news and bad news.
Let’s start with the good news!
I have proposed to apply Domain-Driven Design as a way to build our new but complex green field project and they have accepted.
Cool! And the bad news?
Well, not everyone in the team knows about Domain-Driven Design.
The first thing that I thought is: let’s recommend they read two great books about the subject and after that we can start the project properly. Yes, we are talking about the blue book and the red book.
The blue book is Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. I think is fair to say that this is not an easy book to digest; in my humble opinion it is quite an academic book and written in a style that makes it a bit difficult to follow if English is not your first language. Saying that, I would encourage everyone to read it if you want to build a career working with software.
Every developer should be grateful to authors like Eric Evans who bring to our industry invaluable improvements and raise the bar of our profession. Pearls like that are so difficult to find, but we, as a community, are so lucky that every now an again a title like Domain-Drive Design: Tackling Complexity in the Heart of Software, or Refactoring by Martin Fowler, or Test-Driven Development by Kent Beck appears and makes the reader a better professional.
The second book, the red book, is Implementing Domain-Driven Design by Vaughn Vernon. This is a more practical book; from the beginning the author introduces you to a real-world problem and he applies Domain-Driven Design techniques and patterns to create a solution to solve it. You go through the same concepts as the blue book, but easier to understand because they are expanded upon by using a practical example. And not just that, because this book is ten years younger than Evans’, Vernon introduces you to new concepts like Domain Events, Hexagonal architecture, CQRS or Event-Driven Architectures.
Again, I would encourage every developer to read this outstanding book to improve their skills; even if you have already read the blue one you can review old concepts and learn new ones.
The only problem with these two books (if we can consider that a problem) is the size of them. The former has 560 pages while the latter has 656. They are bricks!
So let’s assume that an average person spends 2 minutes per page in non-technical book (that could increase to 5 or 6 minutes per page on technical material), so this is 30 pages per hour, and let’s assume that they only dedicate an hour per day to read these books. They would need 40 days (or 120 days if we use the speed of 6 minutes per page) to read both books. That’s like two months (or 6 months with the slow speed) before we can start the project.
I don’t think our stakeholders can wait that long.
So, I have decided two summarise these two books and explain DDD to the team. I know this is not going to be an easy task, but it could help me to secure some concepts, because when you explain something to someone else they surprise you with questions that you never thought of before. Wish me luck!
I will write a bunch of posts with my explanations and I will enumerate them here:
About The Author
I’m extremely passionate about knowledge; wherever I go, you will always find a book inside my trusty rucksack - it could be a technical book, a novel, essays; anything that broadens my mind and understanding.
- 18th April, 2018
- 18th April, 2018
- 8th March, 2018
- 31st January, 2018
- 30th January, 2018