tag:blogger.com,1999:blog-19819012.post7413690097169169005..comments2023-06-28T20:26:42.987+05:30Comments on Random Thots: Domain Driven Design without AOPKaushikhttp://www.blogger.com/profile/01004068795704658410noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-19819012.post-90461211149486832962010-01-20T07:28:08.881+05:302010-01-20T07:28:08.881+05:30don't inject any technology(such as Service/Re...don't inject any technology(such as Service/Repository) into business model(entity), decouple "What" from "How". we can use Domain Events pattern to do communication with them. all these have implemented in my famework(DDD framework for Java) jdon.dev.java.netAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-19819012.post-29580492842909570202008-07-28T09:00:00.000+05:302008-07-28T09:00:00.000+05:30@Anonymous...Why doesn't it prevent unit-testing o...@Anonymous...<BR/><BR/>Why doesn't it prevent unit-testing of order?<BR/><BR/>At very best, the only thing I can see is by mocking out persistence implementation from OrderRepository. Which in this case, reduces a lot of SRP-ness of Order unit-test (it becomes more like whitebox integration test).<BR/><BR/>And what benefit does it offer compared to ServiceLocator approach?Hendry Lukhttps://www.blogger.com/profile/16180027255687806862noreply@blogger.comtag:blogger.com,1999:blog-19819012.post-89918749315486743852008-06-19T22:26:00.000+05:302008-06-19T22:26:00.000+05:30Only generic CRUD and querying methods are exposed...Only generic CRUD and querying methods are exposed, plus a few rarely used methods for more special needs that inevitably appear in the real world. The point is to encapsulate and expose everything persistence-related (but not including transactions) needed by a complex business web application, without allowing any unnecessary details to leak out.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19819012.post-86999374852275848692008-06-19T22:12:00.000+05:302008-06-19T22:12:00.000+05:30@AnonymousYour approach looks elegant and simple t...@Anonymous<BR/><BR/>Your approach looks elegant and simple to implement as well. Thanks for detailing it up.<BR/><BR/>Do you only expose generic CRUD methods on the Static Facade or have any specific methods exposed as well ?Kaushikhttps://www.blogger.com/profile/01004068795704658410noreply@blogger.comtag:blogger.com,1999:blog-19819012.post-32968391536191663342008-06-19T21:48:00.000+05:302008-06-19T21:48:00.000+05:30Similar, yes, although the details are probably di...Similar, yes, although the details are probably different. For me, persistence is one of several sub-systems provided by the infrastructure layer. Providing access to this sub-system through a static facade brings several advantages, such as: 1) a way to enforce architectural conventions (such as having all queries use HQL instead of a mix of HQL and Criteria API); 2) a place to hide workarounds for different JDBC driver issues or different ORM tool versions; 3) simplified client code, since the facade can use Java 5 language features such as varargs and generic methods, not to mention the ability to use static imports.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19819012.post-62862482614153189732008-06-19T21:23:00.000+05:302008-06-19T21:23:00.000+05:30@AnonymousJust curious, is your approach similar t...@Anonymous<BR/><BR/>Just curious, is your approach similar to the one described in <A HREF="http://tech.groups.yahoo.com/group/domaindrivendesign/message/214" REL="nofollow">this thread </A> in the DDD forums?Kaushikhttps://www.blogger.com/profile/01004068795704658410noreply@blogger.comtag:blogger.com,1999:blog-19819012.post-43685863625969592008-06-19T21:06:00.000+05:302008-06-19T21:06:00.000+05:30I wouldn't need to inject EntityManager/Session an...I wouldn't need to inject EntityManager/Session anywhere, because I prefer to encapsulate persistence operations behind a static facade. Such a class (say, "Persistence", containing only static methods) can obtain the EntityManager or Hibernate Session (for its own use only) from a ThreadLocal.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19819012.post-31937202328466477242008-06-19T20:24:00.000+05:302008-06-19T20:24:00.000+05:30@AnonymousWhen you instantiate OrderRepository, ho...@Anonymous<BR/><BR/>When you instantiate OrderRepository, how would you inject the EntityManager/ SessionFactory into the repository ? Would the repository look them up from a factory /registry? If they do isn't it the same as getting the pre-configured repository from the Registry.<BR/><BR/>Yes I agree with OrderRepository should be final.Kaushikhttps://www.blogger.com/profile/01004068795704658410noreply@blogger.comtag:blogger.com,1999:blog-19819012.post-85086101505675398362008-06-19T20:15:00.000+05:302008-06-19T20:15:00.000+05:30This is what I would do to get an OrderRepository ...This is what I would do to get an OrderRepository object from Order: <BR/><BR/>new OrderRepository().getPaymentHistory();<BR/><BR/>This is the simplest possible solution, and contrary to what many may think, it does NOT prevent the unit testing of Order. <BR/><BR/>Also, classes such as OrderRepository usually can and should be final, because no alternate implementation will ever be needed in the life of the application.Anonymousnoreply@blogger.com