Package and module structure

[Oscar Picasso <os...@yahoo.com>]

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 the 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.  

RE: Package and module structure

[James Carman <ja...@carmanconsulting.com>]

In HiveMind, you could use symbol sources.  So, let's say you have a
submodule called "accounting" with a package structure like so:

com.myco.myproject.accounting.domain.repository
com.myco.myproject.accounting.domain.repository.hibernate
com.myco.myproject.accounting.domain.repository.cayenne

So, in your module descriptor, you'd replace the hibernate/cayenne part of
the package with a symbol (something like persistence.strategy).  So, (using
BuilderFactory) it'd be something like:

<construct
class="com.myco.myproject.accounting.domain.repository.${persistence.strateg
y}.AccountDaoImpl">
</construct>

James
________________________________________
From: Oscar Picasso [mailto:oscgoogle@yahoo.com] 
Sent: Wednesday, November 23, 2005 4:28 PM
To: hivemind-user@jakarta.apache.org
Subject: Package and module structure

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
________________________________________
Yahoo! FareChase - Search multiple travel sites in one click. 



---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org