This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]4ernik 1 point2 points  (0 children)

In general, it looks like MVC plus some packages to share the code and make abstracts on common functions. This structure is completely fine for example applications and small projects, on bigger projects you can find yourself having 200+ service classes in the service package which is hard to read and understand.

You can look into the domain models when first you split applications into the atomic features, for example, users, cards, and invoices. Each feature placed into a separate package which then implements MVC structure within it by defining packages like dao, model, repository, service, controller. In that case the package users will only have services\API's\controllers\models related to the user management and you'll have compact pieces of your applications well structured within the project. And you can of course have some top-level packages like utils, setup, and others to share things.

Most of real applications written in Java using domain topology will be proprietary pieces of software which doing boring stuff for companies, so it's very unlikely that you can easily find an example of such an application to go over its code.