tag:blogger.com,1999:blog-6959582839690958035.post7073899678511396611..comments2023-09-15T11:15:54.222-04:00Comments on public void Life(): Of Horses and Cartstesthttp://www.blogger.com/profile/09609860522747123959noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-6959582839690958035.post-33162818845218332692010-11-11T11:30:19.175-05:002010-11-11T11:30:19.175-05:00Yeah it's part of DDD that you try to work at ...Yeah it's part of DDD that you try to work at their level figuring out the common language to reliably communicate and think about their domain with and distilling that language and the knowledge they communicate to you in the applications domain model.<br /><br />Now that you have the domain model you can build up processes around them that are valid since you interact with an intelligent domain model and represents how they think and talk about what they do.<br /><br />You could not really understand what the persistence and reporting requirements are until you have started to model the domain. Certainly RDBMS (or swiss army database) can provide you with all of your needs and an ORM can get you back and forth, but it doesn't mean that's the best option.<br /><br />In Applying DDD, Nilsson suggests starting with the domain and during the development of it take breaks to think and work on the persistence. I think this is because the domain model is really the core, but you'll need to evaluate any compromises on persistence to keep yourself realistic. Going for true persistence ignorance could dig yourself some holes.Copenhashttps://www.blogger.com/profile/14860283098628466896noreply@blogger.comtag:blogger.com,1999:blog-6959582839690958035.post-13049629380607163252010-11-11T08:46:02.847-05:002010-11-11T08:46:02.847-05:00One thing that irks me about designing the databas...One thing that irks me about designing the database first is that it assumes all data must be stored in relational tables in a single database. As you mention, making lookup tables for every little enum gets a little tiring. Also, some data just isn't relational. Period. If a data model includes a table with a key and an XML blob, that's a good indication that some of that data should be put into a document or object database, or maybe even flat XML files if it calls for that.<br /><br />Or, based on the needs of the software, maybe the whole of the data model should be partitioned into a couple different databases with considerably more focus placed on performance. Some parts of the business model may be very write-heavy and others very read-heavy. One big normalized structure wouldn't really account for the different "flavors" of data storage required.<br /><br />I definitely like your point about how the business users think in terms of process flow, not in terms of data-at-rest storage. Sitting in meetings with the business users and going over an ER diagram isn't necessarily the best use of their time, nor is it necessarily the best way to get business information from them.testhttps://www.blogger.com/profile/09609860522747123959noreply@blogger.comtag:blogger.com,1999:blog-6959582839690958035.post-50612737992526932732010-11-10T16:40:57.476-05:002010-11-10T16:40:57.476-05:00Your first diagram assumes that they even have a d...Your first diagram assumes that they even have a domain model.<br /><br />I would like to add the phase "smart data structures and dumb code works better then the other way around" from Eric S. Raymond.<br /><br />What I have noticed is that people who design the data model first seem to see the information as just that, data. Then they produce the code that has to operate on that data for everything. I personally see this as producing a dumb data structure meaning that all your code has to be smarter. <br /><br />In a domain model things are object-oriented which is to say that the data is wrapped with intelligence. All the other code interacts with this intelligence and not the data directly meaning there can be a lot less to worry about. <br /><br />Designing the database first doesn't mean you can't end up with a good domain model, but I think you are seriously hurting yourself.<br /><br />I will also say that going database first means that everything has to have a place in the database. I am starting to find it annoying to have enum style tables in the database, or tables that probably would have been fine as a hardcoded class. Not everything has to be configurable. Also I don't like seeing to many enums being switch/if'ed upon outside of construction zones.<br /><br />Oh and let alone that I feel starting closer to how the user thinks about the problem helps greatly with producing more intelligent and useful software. <br /><br />Forms-on-data provides the user with a data centric method for them to unintuitively apply knowledge out of their head. The user most likely wants a task/workflow centric method that aligns to their knowledge.Copenhashttps://www.blogger.com/profile/14860283098628466896noreply@blogger.com