Review on the book Hands-On Domain-Driven Design with .Net Core
A few words before starting the book review. I am big fan of Domain-Driven Design (DDD) and therefore, you can expect my review to be a bit opinionated. In a moment you will find out why.
What is DDD? Well, If you look this question up in Google, you will find a lot of accurate and well described explanations but in my words, I’d say DDD is a set of guidelines which help you through building a much better software from negotiating with business all the way down to the implementation in the code.
DDD is not new and in fact, the term was coined but Eric Evans in his very famous book Domain-Driven Design: Tackling Complexity in the Heart of Software in 2003 (around the time I just started working as a junior .NET developer).
My first introduction to DDD was in 2008 when Jeffry Palermo described Onion Architecture in his very famous article series. Emerging Microservices architecture, moving away from traditional layered architectures and embracing architectural styles like Onion/Hexagonal/Clean, huge demand in scalability and distributing more and more applications are some of the reasons that DDD received a lot of attentions in the past few years in my opinion.
If you have been working in software development industry for more than a few years and on sizable software, then probably the following scenario should be familiar to you.
We start a new software and there are tables like Product and User with reasonable number of columns in the database. After a couple of years, there will be tons of columns in those tables, many of them acting as references and constraints. Every time a new requirement arrives, we may need to make some columns nullable or mandatory and consequently having hard time to figure how this change would affect every other feature. Soon after, performance drops and it becomes a big concern. What if we need to scale the databse?!
We have been dealing with such issues since databased have been and heart of many of software and of course they have not been designed to particularly fulfil our business needs.
DDD is a way to retire databases as the first-class citizens and instead replace them with our business domain. I believe everyone needs to learn DDD. Not because it’s a good solution for every problem (because it’s not) but because adopting every piece of advices in DDD can incredibly be helpful, no matter which way we are using to develop our software.
As I mentioned before, DDD is a set of guidelines but when it comes to the lower level implementation, things become opinionated and that was the reason I bought this book to to examine and compare different ideas. Let’s get to the review now.
If you know Alexey Zimarev or happen to follow him in Twitter, you know he is the person who knows what he is talking about when it comes to DDD. Here is my 2 cents after studying his book Hands-On Domain-Driven Design with .NET Core.
Chapter 1: Why Domain-Driven Design
In this chapter he talks about some useful preliminary topics like complexity and domain and backs his discussions up with scientific published letters.
Chapter 2: Language and Context
This chapter is about introducing some fundamental topics in DDD like ubiquitous language, anemic models, being explicit and impacts of context switching in daily works.
Chapter 3: EventStorming
EventStorming is also something I have become a big fan of in the recent years. The technique was introduced by Alberto Brandolini in 2013 and it’s about bringing visibility to the behavior of the system, breaking complex requirements into smaller and relevant pieces and ultimately extracting the requirements out of that. It’s very practical method and compatible with agile methodologies.
Alexey not only introduces EventStorming process in a practical way, he also shares his experiences and teaches how to act as a facilitator of EventStorming sessions. I very much liked this chapter and was my favorite one.
Chapter 4: Designing the Model
As the title implies, this chapter is all about talking about the models. It uses the result of EventStorming chapter and brings it to the design level and also introduces some other elements in EventStorming.
Chapter 5: Implementing the Model
Up to this chapter, it was mostly theoretical discussions but in this chapter and the following ones author get’s his hands dirty with code. It includes topics like Entities and Value Objects, domain events, ensuring valid states and writing unit tests.
Chapter 6: Acting with Commands
This chapter is about designing API layer (or as the author calls it, edge layer) and implementing Commands.
Chapter 7: Consistency Boundary
A talks about Transactional Boundaries in databases and how to bring the consistency to the domain models instead. Introducing Aggregates and Aggregate roots and finally how they protect consistency of their invariant entities.
Chapter 8: Aggregate persistence
It’s about implementing persistence layer using Entity Framework Core and Raven DB.
Chapter 9: CQRS: The read-side
Author introduces CQRS (Command Query Responsibility Segregation), why it’s needed, why databases cannot be optimized for read and write operations and finally how to write queries.
Chapter 10: Event Sourcing
Another very important pillars of DDD. Author talks about what Event Sourcing is, which kind of problems it solves, and finally building an infrastructure for that in code.
Chapter 11: Projections and Queries
Complementary chapter from the previous one and talks about projections, queries, selections, subscriptions, replaying events, checkpoint and so on.
Chapter 12: Bounded Context
This last chapter is about Bounded Context. A very important topic in DDD. I personally would like it if the author had not chosen this subject as the last chapter of the book and focused more on this topic.
Conclusion
Overall, I very much enjoyed reading this book. It’s a practical book for .NET developers and also application architects. As it’s an architectural book, I do not think it would be best book for beginners or absolute beginners in the software development industry.
