hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oscar Picasso <>
Subject Package and module structure
Date Wed, 23 Nov 2005 21:28:05 GMT
 I read an interesting thread some time ago about "What would be a service?" and "Package
structure for domain classes and services" (see
 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:
 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 the real business model. 
 If I need to solve the business problems related to the users I need to look at 6 different
 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
 2- if you prefer a view of your project based you project based on the use cases:
 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? 

 Yahoo! FareChase - Search multiple travel sites in one click.  
View raw message