Monday, July 10, 2006

Data Driven Design to Domain Driven Design—Facilitator Fit -- Fit

After exploring Fit, I am convinced that Domain Driven Design is way to go.

Data Driven Design creates a communication gap between business user and programmer. Data driven design forces programmer to think more about persistence and data storage needs rather than problem domain. Programmer ends up throwing lot of technical mumbo jumbos at business user. This leads to communication failure.
When business user and programmer arrive at Fit table, next step is to map Fit table to Software’s Business Layer to validate the Fit Table. Mapping will be smoother if Business Layer Class Model mirrors the problem domain. Close mirroring will encourage the programmer to speak in business user’s language and facilitates good communication.
I was employing data driven design with pragmatic use of Design Pattern. Now I am going to focus on Domain Driven Design and speak in Business Users language.
For a start, I am going to read Domain Driven Design by Eric Evans

2 comments:

survic said...

Good posting. However, I feel "domain driven" is a little bit too extreme.

http://survic.blogspot.com/2006/07/domain-modeling-or-data-modeling.html

Vikas said...

Nice post. After reading your post, I wrote this post.
http://vikasnetdev.blogspot.com/2006/07/domain-driven-design-vs-data-driven.html
I reached the conclusion that Domain Driven Design is like automated unit testing for project with multiple releases. It is very important and cost effective in long run. Doing Domain Model Design before Data Model Design or in parallel has some benefits. But important thing is whether you do it at all or not before you jump to coding

How to sell Refactoring to Non-technical Managers?

Refactoring is a disciplined technique of making changes to software code structure, altering its internal structure without affecting its ...