An even simpler and more straightforward approach to organize module contents is to directly put all related classes into this module package in a flat hierarchy. For the users package this means to place all classes, including user related use case entry points, user database access code, potential external system functionality, and the user entity classes themselves, directly into this package.

Depending on the complexity of the modules this can be a clean and straightforward approach or it can become too unorganized over time. Especially entities, value objects, and transfer objects can reach a number of classes that, if put into a single package, drastically reduce clarity and overview. However, it makes a lot of sense to start with this approach and refactor later.

The following shows the package structure of an example users package:

A benefit of this approach is that it's well supported by the Java language. By default Java classes and methods come with package-private visibility. This fact together with organizing all classes in one place leverages encapsulations and visibility practices. Components, that are desired to be accessible from outside of the package, get public visibility; all classes and methods that are only accessed from within this package define package-private visibility. The package can therefore encapsulate all internal concerns.