Hello,
Modern Web Development by Dino Esposito is a well-written, sincere book. There are some good key points that may require you to read certain parts (at least) twice to fully comprehend them. For example, it is only when reading the chapters of the second part that you need to go back and carefully reread the theory to fully justify some of the author’s architectural choices and why things are implemented the way they are.
Having read other books about DDD and ASP.NET in the past such as the
Professional ASP.NET Design Patterns (2010) book by Scott Millett, the one thing that this book greatly helped me with is simplifying the intricacies of Domain-Driven Design. Let’s not forget that DDD primarily aims to attack the complexity of software systems. It seems, though, that more often than not, people talking and writing about DDD tend to offer solutions way more complicated than the problem at hand. Dino Esposito is very honest on this subject: simplify your code as long as it works without compromises in the architectural design. Don’t follow DDD “rules” as if they were carved in stone.
There are some things written in this book that I found confusing. What follows is a list of sentences, terms and examples that I could argue about their comprehensiveness or completeness.
Chapter 1.
The notion of mirroring versus modelling is confusing. It is not clear how the former differs from the latter. On page 3, mirroring is suggested but on the first paragraph of page 4 modelling comes to the rescue.
Chapter 2.
1. I don’t like the “BACK END” label on figure 2-1 on page 20. The term is too broad or even abstract for me. Maybe “DOMAIN” is more suitable.
2. The “Note” on page 24 is confusing. What does it mean, really?
3. The “Scope” example of Value Types on page 25 is incomplete. Value types are immutable. The example should contain code to demonstrate that. Also, the implementation of the Equals method is probably wrong. It shouldn’t contain the reference equality checks! Last but not least, there is a typo in the example. The properties should be named either “GoalX” or “GoalsX”.
4. The “IsGold” method on page 30 is not that useful. A code example could have been provided.
5. The “Using repositories” paragraph on page 35 does not make clear that only the repository interfaces go in to the domain layer. Actually, this is a key point that is missing from the book, even from chapter 13. Certainly, domain services can access the repository but they need to remain implementation agnostic at the same time. Having the interfaces of repositories in the domain layer is the way to go.
Chapter 3.
I found the “What DDD has changed” paragraph on page 50 redundant (it has been repeatedly explained in previous chapters) and frankly, irrelevant to the subject.
Chapter 4.
I found the references on Silverlight and WCF unnecessary. Silverlight, in particular, is a long gone dead-in-the-water technology.
Chapter 5.
Chapter five is the beating heart of the book. The only thing I didn’t like much is the use of the “physical data model” term on page 94. I would prefer “persistence layer”, instead.
Chapter 8.
Figure 8-4 on page 154 should read “Action Invoker” instead of “Action Broker”. This is probably just a typo.
Chapter 10.
1. On page 225, the term “worker service” is introduced out of the blue in favor of the “application service” term.
2. The example on page 226 is nice but too short. I think, a full example is in order at this point.
3. On page 227, it is suggested that the input and view model classes belong to the MVC project of the solution (i.e. to the presentation layer). It should be noted, though, that this applies only if the application layer is there, too. Otherwise, those classes must be moved to the application layer project.
Chapter 11.
The ajax paging solution provided on page 266 is way too complicated and it doesn’t have to be so, really. The same result could have been achieved with a (containing) view, a partial view with both the pager and the grid in it, a couple of action methods and a render action!
Chapter 12.
I didn’t like the “TempData” solution very much. I understand the reasoning behind PRG but this pattern is neither endorsed or promoted by ASP.NET MVC itself. Actually, the authentication code generated by the Visual Studio ASP.NET MVC project template contradicts everything discussed about PRG in this chapter.
Chapter 13.
According to DDD, the rule of thumb is to have one repository per aggregate root and not per aggregate as stated in the second bullet on page 327.
Hope it helps,
In their capacity as a tool, computers will be but a ripple on the surface of our culture. In their capacity as intellectual challenge, they are without precedent in the cultural history of mankind. -
Edsger W. Dijkstra. The humble programmer.