In my opinion, the design department should be quite small, even for a "web-only application."
I would make separate projects for data access and implementation level interfaces, business level and implementation interfaces, as well as the web server itself. I would also make at least one “commons” project to contain code related to more than one of the other projects. But this is only the beginning. I would not hesitate to extract the commons-util project for utility classes regardless of the application being developed (String, Date, Reflection, etc.). I would also like to make a project for useful testing utilities (commons-test). And this is just the next step ...;)
If I wrote normally useful code related to hibernation, I would put it in the hibernate-utils project. Useful Spring utilities will work in the spring -utils project, etc. However, many projects will contain only one or more packages, and packages usually contain several classes.
My reasoning for this is that it helps me think about the code I'm writing. Is this REALLY business logic, or is it general string manipulation, date manipulation, Hibernate logic, etc.? My layers are getting cleaner and it's getting harder to get circular dependencies between packages and projects (we don't want that). It also makes it much easier to reuse code in other projects. There will always be other projects ...
I also found that new developers find it easier to understand the structure because projects are becoming smaller and more manageable; it’s easier to start coding when you feel that you don’t need to stand it all.
As a last benefit to the fine-grained approach, assembly time is reduced because you don't have to build all the time.