Question

In a layered architecture, you have a presentation layer, logic layer and data layer.

So far, I ve been grouping classes into domain, service and dao packages. This represents the model with POJOs/JPA Entities, the business logic and data access layer.

I suppose the domain and services could be grouped to form the logic layer but that leaves a question mark on the presentation or UI layer. Are there any conventions, even unwritten, in terms of grouping classes into packages by their nature in this layer? Or is this left to the appreciation of whoever is leading a project?

As an extra indication, I m experimenting with web applications at the moment and using a "servlet" package to group servlets and a "web" package for ResponseHeaderFilters, ServletContextListeners and utility classes. I would be interested to hear how things are done with a desktop application.

Answer 1

I ve never heard of package naming conventions with regard to the architecture. The only convention or best practise I know is that your package names should start with a unique pattern, most often formed of a reversed domain name (like com.mycompany) or so. Just to make sure that you do not add classes from different libraries to the same package (namespace) which might lead to unexpected side effects.

But anyway, it s increases readability if you name the packages after the tier or usage. I ve seen a scheme like the follwing which I personally liked because it was easy to find and identify the classes, and easy to extend:

com
   .company
           .product
                   .module1
                           .server
                                  .function1
                                            .impl
                           .client
                                  .function1
                           .common
                                  .function1
                                            .impl

Answer 2

I ve never really seen too much of an issue with this.

If you look at the class diagram for your project, you will almost instantly see logical groupings, and the tree structure of the packages tends to map easily to any grouping you need.

using the reverse domain name system (com.company.product...) you will never find a collision even within your own company.

Using Andreas_D s example, under .server and .client you may actually have an additional 3 or 4 levels of packages with dozens or hundreds of individual packages inside it if your project is large enough to warrant that.. but the structure at that level tends to come out of your product design.

Note: This similar question seems to be getting some good descriptions how to use packages:

友情链接