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