Hi,
I read an interesting thread some time ago about "What would be a service?" and "Package structure for domain classes and services" (see http://thread.gmane.org/gmane.comp.jakarta.hivemind.user/1010).
The package/module structure is for me always an unresolved question.
Let's take a simple example for managing users.
You can have:
++ domain
- domain interface: User
- domain class: CayenneUser
If all persistence strategies could use directly POJO, I should not need to separate between interface and implementation. However, cayenne for example requires that your persisted object is a subclass of CayenneObject. So that's the way I have found to avoid dependency on the cayenne persistence framework.
++ persistence
- dao: UserDao
- dao implementation: UserCayenneAccess
I usually also create a CayenneAccessManager to easily switch between persistence strategies but maybe there are some better ways to achieve this goal with Hivemind.
++ service
- service: UserRegistration
- service implementation: UserRegistrationImpl
One possible and obvious package structure would be:
org.mycomp.domain
org.mycomp.domain.cayenne
org.mycomp.dao
org.mycomp.dao.cayenne
org.mycomp.service
org.mycomp.service.impl
This kind of structure makes the life easier for the developer/implementor. You can easily change your persistence strategy by replacing org.mycomp.domain.cayenne with org.mycomp.domain.hibernate and changing you dao factory (for example using an HibernateAccessManager instead CayenneAccessManager).
As am always eager to try new frameworks and strategies, I usually choose this structure. I think, even if it's just a guess here, that you could put you persistence implementation in a separate module/jars and use hivemind to select the right implementation.
However this kind of structure tends to hide t he real business model.
If I need to solve the business problems related to the users I need to look at 6 different packages.
For a more business centric point of view I would prefer something like:
1- if you prefer a view of your project based on the domain model
org.mycomp.user
org.mycomp.products
...
2- if you prefer a view of your project based you project based on the use cases:
org.mycomp.register
ogr.mycomp.sellproduct
...
Both of these structures are closer to the business problems you try to solve. Everything related to respectively an entity or a use case is in one place. On the other hand it makes it more difficult to change the implementation of a layer (for example to switch to another persistence strategy).
Ideally I would like to have a business centric layout while still retain the ability to switch easily between strategies for some layers like the persistent layer.
Any idea if such a goal is reachable?
I that case what would be the packages/modules structure?
Thanks
Oscar
I read an interesting thread some time ago about "What would be a service?" and "Package structure for domain classes and services" (see http://thread.gmane.org/gmane.comp.jakarta.hivemind.user/1010).
The package/module structure is for me always an unresolved question.
Let's take a simple example for managing users.
You can have:
++ domain
- domain interface: User
- domain class: CayenneUser
If all persistence strategies could use directly POJO, I should not need to separate between interface and implementation. However, cayenne for example requires that your persisted object is a subclass of CayenneObject. So that's the way I have found to avoid dependency on the cayenne persistence framework.
++ persistence
- dao: UserDao
- dao implementation: UserCayenneAccess
I usually also create a CayenneAccessManager to easily switch between persistence strategies but maybe there are some better ways to achieve this goal with Hivemind.
++ service
- service: UserRegistration
- service implementation: UserRegistrationImpl
One possible and obvious package structure would be:
org.mycomp.domain
org.mycomp.domain.cayenne
org.mycomp.dao
org.mycomp.dao.cayenne
org.mycomp.service
org.mycomp.service.impl
This kind of structure makes the life easier for the developer/implementor. You can easily change your persistence strategy by replacing org.mycomp.domain.cayenne with org.mycomp.domain.hibernate and changing you dao factory (for example using an HibernateAccessManager instead CayenneAccessManager).
As am always eager to try new frameworks and strategies, I usually choose this structure. I think, even if it's just a guess here, that you could put you persistence implementation in a separate module/jars and use hivemind to select the right implementation.
However this kind of structure tends to hide t he real business model.
If I need to solve the business problems related to the users I need to look at 6 different packages.
For a more business centric point of view I would prefer something like:
1- if you prefer a view of your project based on the domain model
org.mycomp.user
org.mycomp.products
...
2- if you prefer a view of your project based you project based on the use cases:
org.mycomp.register
ogr.mycomp.sellproduct
...
Both of these structures are closer to the business problems you try to solve. Everything related to respectively an entity or a use case is in one place. On the other hand it makes it more difficult to change the implementation of a layer (for example to switch to another persistence strategy).
Ideally I would like to have a business centric layout while still retain the ability to switch easily between strategies for some layers like the persistent layer.
Any idea if such a goal is reachable?
I that case what would be the packages/modules structure?
Thanks
Oscar
Yahoo! FareChase - Search multiple travel sites in one click.
