Customer Reviews

.NET Domain-Driven Design with C#: Problem - Design - Solution (Programmer to Programmer)

5 star:		(3)
4 star:		(2)
3 star:		(1)
2 star:		(3)
1 star:		(0)

 

 

I've been playing with Domain Driven Design off-and-on for about a year now. I've read the Evans book (Domain-Driven Design: Tackling Complexity in the Heart of Software), the Nillson book (Applying Domain-Driven Design and Patterns: With Examples in C# and .NET), and the Fowler book (Patterns of Enterprise Application Architecture (The Addison-Wesley Signature Series)), but what I really need is a real-world reference app to put all these concepts together.

That's what Tim McCarthy's book does. It presents an anotated reference application, a real estate construction management application built as a WPF smart client. McCarthy's writing is clear and to-the-point--he simply provides a running commentary on the reference app from a sequence-of-development perspective. He starts with a skeleton and builds out the app from there, discussing his refactorings as he goes. I find this very helpful as a template for developing my own DDD apps.

The reference app is written in C#, as are the book's code snippets. However, since most of the code discussed boils down to .NET calls, even VB users with only limited experience with C# may find it useful. As C# is my language of choice, it did not present any problem for me.

This is a really good book; the best I've bought in a while. I do not hesitate to recommend it to any developer learning DDD in C#.

I find the book useful in the way it present a design the evolves as the authors attack new parts of the problem area. There are many interesting patterns and ways of dealing with problems that I can see myself using in my own projects.

My main objective is that it can get a bit repetitive. By accident I skipped from the middle of one chapter to the middle of the next. Because of the repetitiveness it took me a while to discover it. At the same time new aspects are constantly introduced so there are still value in the new chapters.

A big annoyance is all the textual errors. It is obvious that cut and paste has been a big part of writing this book, and many times the author has forgotten to update the copied text appriopriately. There is also evidence of the restructuring of the book gone bad, with reference to items not having been introduced yet. It all seems like a bit of a rush job.

Even so, I will give it a pretty high score for the content of the book and the way it can help developers approach their challenges in a good way

This book was entirely describing the design and implementation of SmartCA application using domain-driven design pattern. The author put every detail of steps in building this application from class design classes, creating solution, configuration, writing unit test... I did not run sample code so I did not know if it actually worked. My focus was the design. The author also provides detail of MVC model for SmartCA application

About the topic, the design was very interesting to me. I used this approach in my past company ( about 10 years ago). However, the design in this book was much cleaner with the favor of .Net 3.5. I like the concept of "the domain model is ignorant of how its data is saved or retrieved from its underlying data store or stores" . The introduction of unitOfWork and Repository objects for each aggregate was good in the design. I think chapter 2 was most important chapter. This described the architecture design of the application, what layer needed, how they interacts with each other. This must be understood completely before moving down to the detail. Once the design pattern was clear, the later chapters provided detail implementations. The structure was similar exception each chapter focus on particular aggregate entity.

I think this book is definitely not for C# beginner. It can be a good reference for higher level.

There are some things I don't like.

1. UnitOfWork is broken. What happens when someone adds entity to repository, and then removes it before commiting? The code will try to remove not existing objects from database and then it will add it!

2. Handling of child objects. For example addresses. In any real world app deleting every child object and then adding it again whether there were changes or not would have no place. First performance. Second what If You have to keep history of changes of that child object? What if they have Id's in database and have other children? What if two users work with same objects? What about concurrency? These are problems I have to deal with every day and I would expect some good examples from book writer. Especially that has so many certificates.

3. This book has a lot of repetitive text/code for every factory/repository/service clsss... I would like to have some discussion about problems I mentioned in p.2

4. WPF that nobody knows (yeah some know, but how many WPF have You seen?) shouldn't be used in book about DDD. Do it in WinForms, ASP.NET or even Console app. Why show us WPF? Hell You can't even build sources from this book without going to 3rd party for their GridControl. What's the point of using WPF?


This book is good for someone that doesn't know much about DDD and is doing apps for one user. O

This is a great practical resource for applying concepts of Domain-Driven Design. Tim has put things in a very understandable language however some understanding of DDD concepts is required. The practical .NET example makes it easy for anybody with experience developing in VS and .NET to quickly apply the practices without having to start with a totally blank slate.

The authors and books he recommends are those I would also put on the list as required to have in your library.

I started learning DDD from this book and even with only a basic understanding of DDD concepts I was not lost or left behind.

The goal of this book is to show how one can apply Domain Driven Design (DDD) techniques to building N-Tier .Net applications, using the iterative development of a construction management application as a running example. In order to benefit most from this book, you must at least have some exposure to DDD concepts, and design patterns such as the Repository, Specification and UnitOfWork patterns. In addition, you must also know some Windows Presentation Foundation (WPF) basics because the author uses this relatively new Microsoft technology but does not provide an introduction to it. You will learn a lot from this book, however. Each of the eleven chapters starts out with a problem description, followed by a proposed design addressing the problems at hand, and conclude with annotated implementation code and a lessons learned summary. Some of the things you will learn from this book include: why is it important to draw distinctions between entity and value objects, what are entity aggregates, how do you handle differently the persisting of objects representing aggregate roots, non-aggregate roots, and collections. If you have not previously heard about the Model-View-ViewModel pattern, how it compares with the Model-View-Controller and Model-View-Presentation patterns, and why it might be a good pattern to use when WPF is the presentation technology, you can learn all about it in this book. What will you not learn from this book? You will not learn how to use or integrate Microsoft's Entity Framework into the implementation of an N-Tier application. Although the author had hoped to show how to do this, he explained in the book why he was unable to. Overall, however, I think the book merits a five star rating.

I think that too many of us who code for fun and profit get caught up in the Smart Client Anti-pattern way of programming due to limited resources and the trappings of RAD. That is why so many of the concepts presented in the book are so important - using real structure so that if you get hit by a bus, someone can read your code and do something with it.

The problem with this book is that it is unreadable.

When a book's goal is to present logical design, but does so in a completely haphazard fashion. Perhaps I expected more of a logical design from a book that talks about logical design.

I feel like there was another book I should have read before this book - I just don't know what that book is. Reading this material without some other primer and coming away with a real sense of DDD is like watching 'Empire' and having a real sense of the entire Star Wars series.

You get a lot of 'Do This', but not a lot of 'This is what needs to happen, and here is how we get there...' Maybe after a few more reads I will get more out of this book, but they are long, slow, painful reads. Sorry Tim - I know how hard it is to write technical material on this high of a level, but this is very unfun reading...

This was one book that I was very excited to read. Chapter 2 was when it hit me, this book wasn't what I thought! The entire book is nothing more than a walk-through of an application that the author is building, using DDD. I honestly don't see the point in this book at all, except for putting DDD to practical use, but even still, the author fails to explain some of the concepts in a clean manner. Very often throughout the book does the author make reference to Martin Fowler's book as well as 2 other authors. In fact, the author admits that he wrote this book after reading the other authors' books.

If you are able to learn through osmosis then this book is for you. I was able to pick up some things and I was happy about that, but it just wasn't worth finishing the book. I suggest you read fowler's book based on the numerous recommendations that the author gave.

I've read the othere two DDD books (see other reviewers) and apart from Evans (that was a good book) have been quite disappointed. This book I thought would provide a good understanding of how DDD can be used in real-world production quality apps. If that's what you think this book offers, keep looking!! It actually annoys me to no end when authors, especially ones with such distinguished titles as MVP in Solutions Architecture demonstrate such god awful code that should NEVER make it into a production environment. Taking one example (there are a few) ALL the repositories are subject to SQL Injection attacks. The author may argue that it was done for simplicity, well there's a LOT of pages with that code on it and no-mention (unless I missed it - it is rather repeitive; see previous review) of that it shouldn't be used in real-world apps; in anycase parameterised queries could have been used with only a little extra coding.

So from a lets show you how you could/should code a DDD app in .NET it fails on almost every level.

HOWEVER! His discussions on aggregate roots is quite good and the only reason I gave a 2 star and not 1.

Its unfortunate that there are so little books on the market in this important area for .NET. Hopefully someone will provide a decent one with code they would put into an enterprise application not crap sample code that shouldn't be used by anyone!!