Organization of the package structure

[Demo]

How do you organize your package structure in your application? Especially the service, business and persistence? I've less experience with enterprise applications.

My example:
at.test.Customer.bo --> My Business Objects and Hibernate-Mappings of the objects
at.testCustomer.domain --> Service Interfaces and Implementiations of the interfaces. In the domain I also have my DAO/Persistence.
at.test.Customer.ui --> User Interfaces

Therefore it would be nice to know how you organize your packages to get ideas what can I do better. I know that the structure depends on the problem, but every program has the same basic-structure.

thanks for advice
markus

[Colin Yates]

Excellent question. IMO, most developers do not pay enough attention and cannot justify their chosen package structure. Me included unfortunately

FWIW, I use the following structure:

com.mycompany.project (domain objects)
com.mycompany.project.dao (DAO interfaces)
com.mycompany.project.dao.hibernate (Hibernate implementations of DAO)
com.mycompany.project.util (obligratory utilitys package)
com.mycompany.project.web (general web objects)
com.mycompany.project.web.controllers
com.mycompany.project.web.views

etc. etc.

So you can see I structure by technology (controller, view etc.) and architecture (dao). You end up with a huge number of classes in web.controllers and web.views etc.

I did experiment with not structuring by technology, merely by concept (e.g. use case) and it was a mess

I *do* think it is a very important subject, and raises some very interesting problems, but it never seems to get the attention it deserves.

BTW: I find http://www.clarkware.com/software/JDepend.html to be a really useful tool in analysing package structure.

[manifoldronin]

I did experiment with not structuring by technology, merely by concept (e.g. use case) and it was a mess

I've been a big advocate of "package them by what they do instead of what they are", and it's been working well for me. To me, it's intuitive that classes (including interfaces) should be grouped around the logical concept they represent/implement. To name an (extreme) example, we don't see the JDK core classes organized as "java.interfaces", "java.abstractclasses", and "java.finalclasses", do we?

A typical pitfall here is that people would start with the presentation tier, and organize the classes by use cases, which works out fine, but it becomes vague once it gets to the service tier. The problem here, IMHO, is that when people move from the presentation tier to the service tier, a lot of time they don't realize that, while the concept of "organize by use case" is still right, the _use cases_ themselves have changed. For the services, their "user" is something from the presentation tier. There might be more than one presentation use case (i.e. those normally considered use cases for the whole application) that use one same service use case, or there might be one presentation user case using multiple service use cases.

Not realizing that, a lot of people tend to simply cut all the way through all the tiers vertically when organizing classes, which natually would cause some service classes around the same logical service to be put into different packages, or some other messy situations.

[Colin Yates]

I think I agree with what you are saying, but I don't get what point you are making by listing "java.interfaces", "java.abstractclasses" etc.

I was discussing two different approaches, technology driver (com.x.y.z.web, com.x.y.z.dao etc.) or use case driven (com.x.y.z.booking, com.x.y.z.booking.create) etc.

[manifoldronin]

I think I agree with what you are saying, but I don't get what point you are making by listing "java.interfaces", "java.abstractclasses" etc.

It was supposed to be an analogy to technology-oriented packages like:
com.foo.bar.controllers
com.foo.bar.dao

While it's an extreme analogy, the essence is the same - interfaces, abstract classes, controllers, or dao are all technological terms that don't have to do with any logical perception on the application.

[Colin Yates]

Well I think there is a difference

daos, web tiers etc. *are* conceptual layers, interfaces etc. are much lower. Kinda talking about carparks and shopping malls versus bricks and cobbles

Just to be pedantic