comments on Domain Driven Design again
This is the third time I read it. I believe I finally got it – both its pro's and con's.
I have some comments before,
http://survic.blogspot.com/2006/07/domain-driven-design-data-modeling-as.html but it is still not enough.
Pro's: “Analysis” is not just “requirement gathering”, it is “modeling”, and it goes straight to “design”. DDD make that so clear by using the concept of “ubiquitous language”, deep, philosophical, yet practical. As a result, I will put this book on my recommended book list.
Con's: It claims it has fixed “Anemic Domain Model (ADM)” by a Rich domain model, but it does not! All those “service”, “repository (i.e. DAO)” indicates that the domain entities are still ADM, which is a good thing anyway (a bad name, but a good thing). You may say, then, no harm done, what is the big deal? It is a big deal, because it creates confusions for new developers. Further, it assumes and advocates a narrow-minded and antique “database is not developers business” approach; while in reality, database is the soul of the all information systems. As a matter of fact, all the examples in the book, if you take a "relational database first" approach, you will get the “deeper” (“implicit”, “insightful”) solutions the first time, with no special efforts at all! (that is, if you know the basics of OR mapping, including three ways of handling inheritance). Also, the higher the design level is at (“strategic design”), the more database-oriented it is – traditionally, enterprise modeling (e.g. Zachman framework and data-warehousing) is database oriented, and rightly so. Because senior developers tend to have more responsibilities on enterprise modeling, as a result, this book is actually very bad for senior developers also! In other words, you are looking at the wrong place if you want to have a strategic view -- find a data modeling book, or, data warehousing book!
posted by survic at
10:59 PM
7 Comments:
So, you also brought the Domain Driven Design book ?
This is what I posted in blog in response to comment
Hi Joe,
I agree with your point.
My thinking was Domain Driven Design takes some extra effort and time. It may be hard to sell to client for 2-3 months with no architecture and design in place.
Survic comes from C++/Java background and has database design totally under his control. He does not have to face bureaucracy and obstacles between him and database as lot of us face everyday. He didn’t commit lot of mistakes that we committed using Data Driven Design
http://vikasnetdev.blogspot.com/2006/07/domain-driven-design-vs-data-driven.html
We thought that we have settled this debate
Interesting review on Rocky's book
http://swcses.eponym.com/blog/_archives/2007/1/5/2622285.html
Vikas said: “He has database design totally under his control. He does not have to face bureaucracy and obstacles between him and database as lot of us face everyday.”
---- My goodness! I wish that is true! The real truth is that if I do not control database (the norm), I will find ways to overcome it -- I will never accept it, and I will always get some compromise (e.g., I will be invited in the database design meeting – even if I do not have nay say – usually very soon I will have some say though – because I control the use cases! -- I know, there are always some "friendly" fighting -- my point is, I will always engage such fighting and will win, at least to a satisfactory extent.
In our debate, I emphasized the “small project” point of view, because I deeply believe “divide and conquer”. However, it is not necessary and actually it is an incorrect “strategy” ;-), because the reality is, ignoring database is the result that people do not have the concept of “enterprise modeling”.
That also explains why J2EE is the origin of ADM (anemic domain model), because ADM is the norm in enterprise computing. Also, if you study and participate with data warehousing, and enterprise infrastructure planning, you will clearly see, programming is small scale, data is larger scale -- in the big picture, programming is almost nothing but peripherals.
Modern OO (for entity objects) is easy, because distributed computing does not allow it to be too rich and complicated. Again, it is a compromise, but it is better than antique OO that is delicate and intensive in details, but a total mess in large scale.
Never make entity model "rich" -- it is simply evil to do that in large projects. Keep it simply (i.e. ADM!), even it means you will use some procedure style in the mix! A complicated (“rich”) OO for entity model is worse than procedural mix! Believe me.
As for the origin of the above “insight”: I guess OR mapping is the key. After you use OR mapping for a while (note that entity bean is a kind of OR mapping, it sucks though), you will never think databases are separate from applications! Also, you will dislike stored procedures, and strongly typed collections. One stone, three birds -- it is all because of OR mapping -- you need to use it for a few years in order to get the insight, because you need sometime to unlearn the old habits – it is a slow process, because you can certainly keep thinking databases are separate, and keep using stored procedures, and keep using strongly typed collections, it is just that they are not advantageous anymore, on the opposite, they are burdens, and gradually, you will forget them.
survic
Yes, OR mapping is the source -- now I know why I have so much fighting with people in CSLA amd DDD.
http://www.avocadosoftware.com/csblogs/dredge/archive/2007/02/19/687.aspx
thank you vikas! I put all those similar voices in one place, a new blog, of course.
dredge's post is amazing!
survic
I was thinking of adding these links to your post on CSLA. We had similar discussion on your blog.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home