tag:blogger.com,1999:blog-11393788.post115492290234589049..comments2024-03-09T00:32:10.709-08:00Comments on Vikas's Technical Blog: Domain Driven Design based on Entity Model vs E/R ModelVikashttp://www.blogger.com/profile/11330187546301885403noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-11393788.post-1155148873489941442006-08-09T11:41:00.000-07:002006-08-09T11:41:00.000-07:00I agree with you now, 100% :-)The database storage...I agree with you now, 100% :-)<BR/><BR/>The database storage details -- you are right: I have to hide them if they are too messy. If I insist on the “data driven” stuff, then, I have to cheat, and persuade myself with the differences among conceptual/logical/physical data models.<BR/> <BR/>However, as you may guess, I do not like those demarcations; because the advantage of database is that the turn-around time between schema design and real data (the “manual Fit”) is within minutes. <BR/><BR/>More about “manual Fit”: I remember that originally (in the age of DB2 and Oracle) relational databases were build under the assumption that users are supposed to use sql/plus directly. That is the spirit of “manual Fit”! <BR/><BR/>Admittedly, it turned out that it was an invalid assumption, however, business analysts, or, developers who wear analyst hats should do such “manual Fit”. <BR/><BR/>Anyway, I found “manual Fit” is a good concept. I am going to use it everywhere. On the other hand, it adds some non-pure-OO elements to Fit though ;-)survichttps://www.blogger.com/profile/05621218802357307115noreply@blogger.comtag:blogger.com,1999:blog-11393788.post-1155092426869938982006-08-08T20:00:00.000-07:002006-08-08T20:00:00.000-07:00Survic wrote “So, if it is a new database, we desi...<B>Survic wrote <BR/>“So, if it is a new database, we design it ourselves; if it is a legacy one, then, we need the data within it. Either way or both ways, we need to deal with database early on.”</B><BR/><BR/>Let us keep the context right.<BR/>So, if it is a new database, we help DBA to design ; if it is a legacy one, then we need the data within it. Either way or both ways, we need to deal with DBAs early on. DBAs will have their own deadlines and their own priorities.<BR/><BR/><BR/>Now I will switch to your context. When you are designing the database , it is very important to make sure that you have all the data that user is asking for reporting. One can use Screen Mockups, relevant E/R diagram(60% to 90%), Process logic in form of (Class diagrams, Sequence Diagram, activity flow charts) to communicate with users. That is perfect. My contention was that while it is okay, do the database design simultaneously but hide it from user by exposing them to entity domain model. A model which uses vocabulary with which users are more familiar but hides the complex storage and retrieval details from users will be more useful. But if you think that it will waste of time. I again agree with you 100 percent.<BR/><BR/><B>Survic wrote<BR/>I am waiting for your ideas on a domain model without being “anemic". </B><BR/>I did write how I see Domain Model as one level abstraction over database hiding the data storage and retrieval.<BR/>Domain model will be anemic from 60% to 90%. Let me tell you about my experience of Domain Driven Design. I was working on a project six years back with DBA in charge of Database Design and we were pulling lot of data from legacy system. So, database diagram was a secret till the end of design phase. We, developers did give lot of inputs about data requirement and how we think that certain aspects of data storage should be like. Besides creating the Screen Shots, data flow diagrams, I also prepared a Domain Model by finding all the actors and their characteristics/behavior. Finally I optimized my domain model by decomposing the entities that have one-to-one relationship in single entities.<BR/>When I saw the database E/R diagrams at the end of design phase, it exactly matched my domain model. I felt like a fool but it was not in my hand. My regret is that I didn’t scope the process classes in design phase. I ended up writing a thin client with all process/workflow/co-ordination logic in the UI Layer. I corrected this during refactoring in next phase of development. We were following waterfall methodology.<BR/>I think that it is criminal not to use E/R diagram when it Is handy, to derive the entity classes. Somewhere you have to stop being self-righteous and deliver solutions to users when pay you your monthly check. <BR/><BR/><B><BR/>Survic wrote:<BR/>I have seen a lot of derogative comments about it, but have seen nothing that can solve the problem<BR/></B><BR/>You should sugar-coat it to Object Purists by saying “Let us use Database diagram as a starting point for our Domain Driven Design.” And you can stretch the starting point as much as you likeVikashttps://www.blogger.com/profile/11330187546301885403noreply@blogger.com