构建我们的Java包

Question

This is some experimental thinking going on here about how to layout your Java packages.

As Java developers we have seem the following layout in one form or another probably a gazillion times:

com.example.service.rest  
UserRestService.java  
BookRestService.java  
TaskRestService.java  

com.example.service.rest.impl  
UserRestServiceImpl.java  
BookRestServiceImpl.java  
TaskRestServiceImpl.java  

com.example.data  
UserDTO.java  
BookDTO.java  
TaskDTO.java

I have been a consumer of such a layout for years.

I was briefly involved in a NodeJS project where the layout was completely different and I just loved the flatness, the simplicity, and the containment of every component.

In comparison to what I got used to it felt like my classes are ( the above layout ) thrown about as if an exp;lotion taken place.

The NodeJS project layout ( translated to Java ) would look like this:

com.example.service.rest.user  
UserDTO.java  
UserRestService.java  
UserRestServiceImpl.java  

com.example.service.rest.book  
BookDTO.java  
BookRestService.java  
BookRestServiceImpl.java  

com.example.service.rest.task  
TaskDTO.java  
TaskRestService.java  
TaskRestServiceImpl.java  

The NodeJS layout I adopted this from had a very flat structure where every directory / package would contain the rest controller, the service, and the DAL/DAO.

Felt like everything was broken into organized micro buckets.

Has anyone ever tried the second approach on a larger scale before?
Any thoughts you have on the first layout vs the second layout?
Any reading resources on the subject?

Answer 1

You can lay out your packages any way that makes sense. What you called a "NodeJS" layout is quite common in Java code. Each API might have its own logic driving package organization. It's part of the art of computer programming to choose a package layout that supports maintenance effectively.

I really don't see anything essentially different between the one strategy and the other. They're both arbitrary and could serve different projects. I suggest that you use the one that makes the most sense for you, the team, and the individual project.