Service classes should handle transactions this way even if the transaction spans multiple domain objects, the service class can manage the transaction since in most of the use cases the Service class handles the control flow. This results in too fine-grained transaction control which doesn't give the flexibility of managing the use cases where the transactions span multiple domain objects. Some developers prefer managing the transactions in the DAO classes which is a poor design. Good so far, but Srini Penchikala on InfoQ article states: The domain model either directly or indirectly via a façade, which as Iĭescribed in the previous chapter is either a POJO or an EJB. The presentation tier handles HTTP requests from the user’s browser by calling
DOMAIN DRIVEN DESIGN JAVA EXAMPLE HOW TO
Problem is, that I don't know, how to organize transactions in my application.
It's not considered a good practice since it leads to the procedural code, so I wanted to move forward to the domain driven design.Īfter reading couple of articles on the web, listening to the Chris Richardson's talk on Parleys and reading DDD chapters of the POJOs in Action, I think I got the big picture. This pattern is called Transaction script. I used to design my application around anemic domain model, so I had many repository object, which were injected to the big, fat, transaction-aware service layer.
0 kommentar(er)
