-
1. Re: Domain Driven Design with Seam
jpviragine.jpviragine.gmail.com May 2, 2008 3:50 PM (in response to thejavafreak)Joshua,
Take a look at Seam Framework
I would recommend the chapter 10 from the amazing Seam in Action
Regards
-
2. Re: Domain Driven Design with Seam
infinity2heaven May 2, 2008 3:56 PM (in response to thejavafreak)As Joshua mentioned, take a look at Seam
Application
Framework (an ambiguous name though). Seam doesn't recommend domain classes to persist itself like RoR and there are reasons to do that. By the way, I'm not sure why you think Domain Driven Design means having persistence in the entity objects itself. It merely is a methodology to model complex business models from a business/domain point of view (top down approach), rather than thinking of database tables and schema design (bottom-up approach). Designing a domain model, annotating them with persistence mapping and letting them generate the schema would fit in a domain driven design.Currently, we have the same approach and it works great with Seam/hbm-ddl tool.
-
3. Re: Domain Driven Design with Seam
thejavafreak May 2, 2008 3:59 PM (in response to thejavafreak)
Joao Viragine wrote on May 02, 2008 03:50 PM:
Joshua,
Take a look at Seam Framework
I would recommend the chapter 10 from the amazing Seam in Action
RegardsAha. I see. The problem is that your domain object still don't have any behaviours other than getters and setters, and you still need to pass this domain object to the Home object. But what I really want is that the behaviours is inside the domain object instead of the Home object. Has anyone tried this before?
Thanks in advance
-
4. Re: Domain Driven Design with Seam
thejavafreak May 2, 2008 4:03 PM (in response to thejavafreak)
Priya M wrote on May 02, 2008 03:56 PM:
As Joshua mentioned, take a look at SeamApplication
Framework (an ambiguous name though). Seam doesn't recommend domain classes to persist itself like RoR and there are reasons to do that. By the way, I'm not sure why you think Domain Driven Design means having persistence in the entity objects itself. It merely is a methodology to model complex business models from a business/domain point of view (top down approach), rather than thinking of database tables and schema design (bottom-up approach).Yes I think you get the idea what I'm trying to say here. I still don't get it why Seam think is not a good idea for having the persistence in the entity objects itself? Wouldn't that encourage you to re-use your domain model accross different apps?
Designing a domain model, annotating them with persistence mapping and letting them generate the schema would fit in a domain driven design.
Currently, we have the same approach and it works great with Seam/hbm-ddl tool.Could you please give me a snippets on this so I can get the idea what you're tying to express?
Thanks in advance
-
5. Re: Domain Driven Design with Seam
jpviragine.jpviragine.gmail.com May 2, 2008 4:06 PM (in response to thejavafreak) -
6. Re: Domain Driven Design with Seam
infinity2heaven May 2, 2008 6:12 PM (in response to thejavafreak)
Could you please give me a snippets on this so I can get the idea what you're tying to express?Have a look at the hotel booking example of Seam. DDD works best for a new project where the db doesn't exist. (where you have your own db schema, you have to play around reverse engineering the domain model or the mappings)
1) Domain model is annotated with all the mappings
2) hotel booking entities doesn't have much business logic, but it's perfectly alright to have some logic like calculateWeekendRate() or calculateDiscounts() inside Booking domain objects (which doesn't have any dependencies on third party API). The key is that it's still a pojo.
3)In persistence.xml , provide hbm2ddl options
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
or for a stable domain model,
<property name="hibernate.hbm2ddl.auto" value="validate"/>
That's pretty much the basics for a Domain Driven Design. Let the domain model speak your business, have the business concepts named as domain objects rather than tables and join-tables. And if possible, have similar naming conventions using ImprovedNamingStrategy for database tables too.
Peristence is best delegated to DAO or in case of Seam EJBHome/EJBQuery as it separates out concerns. You want to share the domain objects across all the layers but without the cost of all the javax or hibernate imports in the same object.