tag:blogger.com,1999:blog-20576845.post67570263705911305..comments2024-03-15T16:44:45.322+01:00Comments on Ziobrando's Lair: Domain Driven Design in Java: Repositories and DAOsAnonymoushttp://www.blogger.com/profile/00568728817611163214noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-20576845.post-81731264115179549682008-03-11T10:36:00.000+01:002008-03-11T10:36:00.000+01:00Hi, thanks for the link.The main point here is tha...Hi, thanks for the link.<BR/><BR/>The main point here is that the pure DDD approach makes perfectly sense if one does not consider capabilities provided by frameworks, which have been evolving in the meanwhile. Being too strict on the DDD principles might make you lose the competitive edge of a newer technology, while going straight on the technology could make you stuck with code that's easy to write but definitely hard to evolve.<BR/>Unfortunately you're not so lucky to know all the project ecosystem in advance...Anonymoushttps://www.blogger.com/profile/00568728817611163214noreply@blogger.comtag:blogger.com,1999:blog-20576845.post-13804386419557707012008-03-10T21:16:00.000+01:002008-03-10T21:16:00.000+01:00Regarding the difference between Repository and DA...Regarding the difference between Repository and DAO, one point of view seem to be that a Repository can be implemented by delegating to a DAO.<BR/><BR/>Here is a quote from DDD authour Eric in the DDD discussion group: <BR/>"If your infrastructure makes it much easier to return DAOs from whereever these things are being stored, then fetch the DAO *inside the repository* and use the data to create a Category object *inside the repository*. "<BR/>Source:<BR/><A HREF="http://tech.groups.yahoo.com/group/domaindrivendesign/message/3715" REL="nofollow">http://tech.groups.yahoo.com/group/domaindrivendesign/message/3715</A>Anonymousnoreply@blogger.com