Saturday, July 15, 2006

Domain Driven Design vs Data Driven Design -- Domain Driven Design

Subscribe to my youtube channel "Software Architecture Matters!!!"

Survic has very nicely argued that database storage and retrieval is 80% ( I would say 70%) portion of application. Mocks ups, Screen Design and database will help to achieve completion of 80 percent of system.
I agree 100% with you that if you have a short term project with no future releases, data driven design is more efficient. My argument is Mock ups, Domain Design and Database Design (in that order. Domain Design and Database Design could be parallel activities in some organizations) will not only help achieve 100% but is also cost effective for project with multiple releases.

Rest of 20% is too important to left open to risks of communication failure
Nothing more make sense to Business User more than Mock ups, Screen Shots or prototype. You win the 80 percent battle if you have these ready with Database design. But left 20% is too important to left open to communication failure.
Rest 20% is like collaboration mechanism that integrates all the parts of plane and help you fly the plane and reach the destination. Fact that you all parts are complete and you get the mechanism wrong would result in system failure.
Now back to real world, we get the 20% right in the sense; they deliver the business value but are written in procedural style hard-coded in the front end. Thus it results in weak business layer. Experience developers will notice patterns and in next iteration, we will refactor the 20%. That brings me to next point

Domain Driven Design requires more time.
Domain Driven Design is a more reverse thought process. As you put it, first figure out the data needs and perform the domain design. Problem is thinking in terms of data needs will create communication failure. There is good case study example in Domain Driven Design ( I have read only 10% of book). Here is excerpt from book


So when we change the customs clearance point, we need to redo the whole routing plan.

Right. We'll delete all the rows in the shipment table with that cargo id and we will pass the origin, destination, and the new customs clearance point into the Routing Service, and it will re-populate the table. We'll have to have a Boolean in the Cargo so we'll know there is data in the shipment table

Delete the rows. OK, whatever

Reference: Domain Driven Design -- by Eric Evans.

There is no concept of any domain analysis in most project that I have done. You have screen shots, process flow or activity diagrams and database ready, let us move to development. Class diagrams more reflect the database rather than domain.
So you are going to be get all entity classes right and no or light controller or process classes. Experienced developers will notice all common patterns but there is not time to apply patterns as there is a deadline to meet. In next release, experienced developers will sneak in design patterns, controllers and process classes. If something breaks down in application that was scoped not to be affected during impact analysis in release, you will to answer the Project Manager.

Domain Driven Design is good and no Domain Driven Design has costs
In my analysis, Domain Driven analysis will help you get 10 – 15% out of 20% right in first release. Returns on investment are higher in long term and less risk. Performing Domain Analysis first before data requirement will help the communication and no Domain Analysis has costs.

People understand Mock Screens More
In theory, perhaps, you could present a user with any view of a system, regardless of what lies beneath. But, in practice, a mismatch causes confusion at best—bugs at worst. Consider a simple example of how users are misled by superimposed model of bookmarks for Web sites in current releases of Microsoft Internet Explorer.

Of course, an unadorned view of the domain model would definitely not be convient for the user in most cases. But trying to create in the UI an illusion of a model other than the domain model will cause confusion unless the illusion is perfect.

People don’t understand Objects
MODEL_DRIVEN DESIGN calls for an implementation technology in tune with the particular modeling paradigm bend applied. At present, the dominant paradigm is object-oriented design and most complex projects these days set out to use objects, some are circumstantial, and others derive from the advantages that come from wide usage itself.

Many of reasons teams choose the object paradigm are not technological, or even intrinsic to objects. But right out of the gate, object modeling strike a nice balance of simplicity and sophistication.

The fundamentals of object oriented design seem to come naturally to most people. Although some developers miss the subtleties of modeling, even non technologists can follow a diagram of an object model.
Yet, simple as the concept of object modeling is, it has been rich enough to capture important domain knowledge. And it has been supported from the outset by development tools that allowed a model to be expressed in software.

Objects are already understood by a community of thousands of developers, project managers, and all other specialists involved in project work.

When a design is based on a model that reflects the basic concerns of users and domain experts, the bones of the design can be revealed to the user to a greater extent than with other design approaches. Revealing the model gives user more access ot the potential of the software and yields consistent, predictable behavior

Reference: Domain Driven Design – by Eric Evans


survic said...

I put my reply blog here.

Note that although I do not agree with your take on the topic; I do appreciate your analysis greatly. A lot times, the analysis process itself is more important. Keep up the great work!

Vikas said...

Yes, we are getting close. Domain Driven Design is going to get two new practitioners or none.

Let get the context right.

Data Driven Design wins hands down for small project.

I will be lying to you if I say that I don’t use Data Driven design for most of projects the way you described. I also thought that it is pragmatic and cost effective approach. Create the Mock ups, design the database and derive the entity classes in free.. Then design the controllers and process classes and get the job done. I also held the belief that Domain Driven Design and/or CRC Analysis is for crazy guys with beards who write books.
When reading Fit, I realized that Domain Driven Design may be better approach when I thought the system from business user perspective.

Before going further, I am still exploring the Domain Driven Design. I have not uet joined the other side. I have just read 20% of book. Feel free to correct me if you think that I am wrong. I am excited about Domain Driven Design otherwise I would not have spent 50$ and wasted my time to read it. After finishing it, I am going to rate this book either 1 out of 5 or 5 out of 5. This is one of few books in which I am going read case studies. Generally I skip them and use in real practice. Be paitent with me. :)

Important thing is to get Entity, Process and/or Controller classes right.

Question: What if you are not designing the database but the powerful DBA ?
You don’t get the opportunity to design the database, though you may provide the inputs to DBA . DBAs design the table and they have their own way of designing for consistency and extensibility. In real enterprise environment, you have to face O/R mapping waterloo. It may make more sense to Invoice Entity object to have Paid attribute as Boolean(ture./false) but in database , you may be storing as 1, 0 because it was decided by DBA to standardize in database or database does not offer Boolean data type.

Data Driven Design could ignore Controller and/or process classes

90% of people who user Data Driven Design, ignore controller or process classes. Correct me if I am wrong. Couple of years back, I was guilty of same crime until I came across design patterns and I have never look back since then. Either I design good Object Model or bad but it is never procedural. 100% of prople who employ Domain Driven Design, get some controller and/or process classes right in first iteration or phase.

Class Diagram in conjunction with Activity Diagrams and/or Sequence Diagrams communicates more clearly than Database Diagram

Imagine a user showing following Table


Imagine a User being shown following class


Which would make more sense to Business Users

By doing the above, you can successfully avoid the prototype data modeling. and say “See Mom no prototype ERWin Diagram” . Real ERWin Diagram may be prepared by DBA. Or you may just to map entity classes to Database Diagram.

You may say that when you are design entity classes , you are designing actually database table.

to be contiued...

Note: I may revise this post after completing the book for good or bad

Vikas said...

added two more sections to th post

1. People understand Mock Screens More

2. People don’t understand Objects but User Interface

Domain Driven Design – by Eric Evans

Vikas said...

Vikas’s Thinking Starts
Since I am locked in mortal combat with Survic over Domain Modeling vs Data Modeling. Here is my strategy, concede tactical defeat to Survic. Fight Survic on my favorable grounds and make sure Survic cannot use his best weapons ‘Small projcts’ in his arsenal and win the strategic battle. Here comes my offense
Vikas’s Thinking Ends

Hi Survic,

I agree with you that Data Modeling wins hands down for small project and when programmer is also designing database.

What would you suggest in a environment when you are not in charge of database design.but DBA.? Do you agree that kind of environment exist? I had been in those environments. Would you wait for DBA to finish Database design and get caught with out a domain model in Design Phase? Mock screen are simply illusions of design and implementation which has to backed by Domain or Data Model. What is approach do you suggest in such situation? Taking DBA out of equation is not any option and project duration is 10 months

I have added more thoughts to my posts

Vikas said...

I found a nice blog.
I just read Domain Driven Design section of blog

I was really excited to read domain driven design and went through same emotions while reading the book. My criticism of book that most of the patterns book discusses I am aware of . May be I should have read books few years back.

Vikas said...

survic wrote "I felt I need more definitive source to support my point of view. I did some research; frankly, I have to admit that I am not on the mainstream"

Because we solve real problems for paychecks not make living out of writing books.
Jokes apart, our focus has been more on tactical projects (1-6 months) where Data Driven Design works fine. Rocky, Martin and Eric focus is more on strategic projects which span over multiple years and have layers of bureaucracy.

Vikas said...

Survic wrote
"However, I do find a source: I did not dig into it too much; and from what I saw, it did not go to the extremes as I did, but it shares the same points: database should be in the domain modeling picture, and developers should use data modeling as one important source of information. "

I read the Object Primer and found the following tit-bits.
Conceptual Modeling or Domain Modeling
Various types of Model you might want to use for conceptual domain modeling

1. Robustness Diagrams;
2. Object Role Model(ORM) diagrams;
3. Class responsibility collaborator(CRC) models;
4. UML class diagram
5. Logical data models(LDMs);
6. Analysis patterns;
7. UML object diagrams.

The fit between object technology and RDB technology is not perfect. In the early 1990s, the difference between the two approaches was labeled the object/relational impedance mismatch, also referred to as the
O/R impedance mismatch

or simply the impedance mismatch; terms still in common use today. Why does a technological impedance mismatch exist? The object-oriented paradigm is based on proven software engineering principles. The relational paradigm however is based on proven mathematical principles. Because the underlying paradigms are different, the two technologies do not work together seamlessly.

There is also a cultural impedance mismatch between developers in the object community and data professionals in the data community. Object developers have been taking an evolutionary approach to developments for years and now moving towards agile development methods such as extreme programming. Unfortunately many within the data community look upon evolutionary development as a questionable approach, and agile approaches are just now being considered.

When it gets right down to it the real issue is that data professionals view the world as data to be manipulated, whereas object developers view it as objects to be combined to perform behavior.

Data are important.

Data are one of many issues. Although data are important , so is telecommunication, user interface development, working with stakeholders, buinsess component architectures, frameworks, understanding the business domain, and so on.It is quite common for data professionals to overestimate the importance of data, which is unfortunate.

You need to look at the enterprise pictures. Luckily data professionals are often very good at considering enterprise –level issues-yet another reason developers should work with them closely.

Everyone needs to work together.

Common legacy data challenges
I am listing some from book

1. A single data field is used for several purposes.
2. The purpose of a data field is determined by the values of one or more columns.
3. Inconsistent values are being stored in a single data field
4.There is inconsistent/incorrect data formatting with in a column.
5.Important entities, attributes and relationships are hidden and floating in text fields.
Data values can stray from their field descriptions and business rules.
6. One attribute is stored in several fields.

My Comments
Context: Big projects. DBA doing the database design
it is more important to nail down requirements in Design rather than figuring out Data storage requirements. Because of O/R impedance, one may put extra effort into data storage effort rather than in discovering the problem domain.It is okay that data storage requirement activity to span over construction but not requirement gathering. If requirement gathering activity spills into construction, it can be very expensive

Tomorrow, I am going to post Rocky's comment on O/R impedance.

Vikas said...

Now I understand why O/R mapping is such a big subject in J2EE environment not in .Net environment.

Vikas said...

Continued to ...

Joe Reddy said...

I think you two are looking at this from the wrong angle. The size of the project does not determine whether you do a business or data-centric design. The need does. Is the system no more that a database babysitter (moving data in and out?) like contact management, or task management? Or is it the representation of a business full of rules and logic.

My guess is nearly every common business application is a mix of both. My guess is that in Survic’s experience he has worked more with applications that truly are all about the data.

And lastly, any application that has a future of being changed by the user’s changing needs or desires benefits from users who understand the object model. From my experience, users find it pretty interesting to learn that we write programs with parts that match their real-world objects.

Vikas said...

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

survic said...

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.