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


survic said...

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

Vikas said...

Nice post. After reading your post, I wrote this post.
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

F12 Developer Tool is your friend.

I was recently debugging Web Site functionality issue with a client. We were not able to reproduce the issues at our end. I saw that the c...