tag:blogger.com,1999:blog-20196010.post114848368156025284..comments2023-04-02T10:19:37.644+02:00Comments on Frederik Gheysels' DevLog: Domain Driven Design: A Quickstart (Part 1)Frederik Gheyselshttp://www.blogger.com/profile/15416462808733991725noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-20196010.post-1153159653415577242006-07-17T20:07:00.000+02:002006-07-17T20:07:00.000+02:00Ik ben er mee bezig... Echter, door de hitte gaat...Ik ben er mee bezig... Echter, door de hitte gaat het niet zo snel vooruit. :)<BR/>Een eerste draft is er al, en ik hoop van tegen het einde van deze week, of anders in de eerste week van augustus het definitieve artikel te kunnen posten.Frederik Gheyselshttps://www.blogger.com/profile/15416462808733991725noreply@blogger.comtag:blogger.com,1999:blog-20196010.post-1153156863986444572006-07-17T19:21:00.000+02:002006-07-17T19:21:00.000+02:00Waar blijft de follow-up? ;)Waar blijft de follow-up? ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20196010.post-1150805770224595242006-06-20T14:16:00.000+02:002006-06-20T14:16:00.000+02:00I can't agree more with you last argument.But i st...I can't agree more with you last argument.<BR/><BR/>But i still think there are to much developers that stick to the RDBMS and don't try alternatives, except that short Xml-hype ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20196010.post-1150463209167652322006-06-16T15:06:00.000+02:002006-06-16T15:06:00.000+02:00The problem is that it is not always the developer...The problem is that it is not always the developer (or dev-team) that can choose which tools to use (RDBMS / ODBMS).<BR/>In a lot of cases, you'll have to write an application that has to work with data that is already available in an RDBMS. In those cases, it is not a good idea to migrate the RDBMS to an ODBMS.<BR/>Next to that, I haven't met a lot of people who have experience with ODBMS'es, so, finding people that are proficient with ODBMS'es is not an easy task.<BR/><BR/>Also, I do not think that you should sacrifice the advantages of an RDBMS just because it is easier to use an ODBMS when you're developping an OO application. A good O/R mapper will bridge the gap between the OO Model and the RDBMS, this means that the cost of bridging the O/R mismatch can be highly reduced.<BR/><BR/>And, in DDD, the way of persisting the data is actually an implementation detail. The domain should not be aware of how the objects are persisted, and where they come from. <BR/>The Repositories should make abstraction of that. So, in DDD, it really doesn't matter on how the data is persisted.Frederik Gheyselshttps://www.blogger.com/profile/15416462808733991725noreply@blogger.comtag:blogger.com,1999:blog-20196010.post-1150444532489577082006-06-16T09:55:00.000+02:002006-06-16T09:55:00.000+02:00Why I do not use an ODBMS in this example:- ODBMS'...Why I do not use an ODBMS in this example:<BR/>- ODBMS'es are -imho- not widespread. They're not used a lot, and personally, I do not know any project myself that uses an ODBMS.<BR/>An RDBMS is a proven technology, and imho still the best way to store critical data.<BR/>- Relational Databases are a great way to store data efficiently, and storing data in a relational way, is also great if you want to make reports on the data. In a Business System, Reporting is a very important issue. Creating reports from an ODBMS is -imho- not as easy.<BR/>- When you use an ODBMS, this means that you'll have to put your domain model in your DB as well. Then, what if another application needs to work on the DB as well, but, has another perspective on the data ?<BR/>- What if you have to build a new application on an existing (Relational) Database ? <BR/><BR/>You're right that developing the OR is very expensive; it takes a lot of development if you do it yourself.<BR/>However, if you use an existing O/R tool like NHibernate, WilsonOR, ... it will greatly reduce your development time.<BR/>Using an ODBMS in this example would surely be easier for me. However, since I think most people still use RDBMS'es, I think it is better to discuss DDD with the combination of an RDBMS in this article.<BR/>Another thing to take into consideration: ODBMS'ses have been around for quite some time now, but, they're still not widely used. I wonder if ODBMS'es will eventually replace RDBMS's, but at this time, I'm not convinced that this will happen.<BR/>In other words: I do not think that ODBMS'es will replace RDBMS'es over time.Frederik Gheyselshttps://www.blogger.com/profile/15416462808733991725noreply@blogger.comtag:blogger.com,1999:blog-20196010.post-1150357678474418162006-06-15T09:47:00.000+02:002006-06-15T09:47:00.000+02:00Because you have a great missmatch with the Domain...Because you have a great missmatch with the Domain Objects and your RDBMS, why don't you use or suggest ODBMS?<BR/><BR/>Normally you loose a lot of time in and with developing the OR and it is allways the same story, create your UML of you Domain Model, create a relational Database Model and then create a mapping for your RDBMS and Domain Model. This mapping is allways a lot of code, costs a lot of time and gives a lot of problems and questions.<BR/><BR/>I know there are some good reasons why an ODBMS would not fit in a project, but i wondered why you talked a lot in this post about OR but only uses the most missmatching type, an RDBMS?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20196010.post-1148975465840686462006-05-30T09:51:00.000+02:002006-05-30T09:51:00.000+02:00This is an interesting (long) post. I did not hav...This is an interesting (long) post. I did not have a notion about Domain Driven Design until I have read your post.<BR/><BR/>It seems that DDD can provide a very clean solution to some complex domain because you do not have to take care of storing/synchronizing/... the collections in your domain model. I think this is something the repositories have to take care of.Anonymousnoreply@blogger.com