Sven Plath
Sven Plath

Reputation: 558

Structure Java packages by “layer” or by “type”?

Consider the following example.

There is a server application that has three layers. The service layer that is exposed to the clients, the database layer that is used for persistence and the business layer that calculates something.

The application serves three different types of data. Users, Payments and Worktimes.

How should I package my application? Package by layer:

foo.bar.service
  UserService.class
  PaymentsService.class
  WorktimeService.class
foo.bar.persistence
  UserPersistenceService.class
  PaymentPersistenceService.class
  WorktimePersistenceService.class
foo.bar.business
  PaymentCalculator.class

Or package by type:

foo.bar.user
  UserService.class
  UserPersistenceService.class
foo.bar.payment
  PaymentService.class
  PaymentsPersistenceService.class
  PaymentCalculator.class
foo.bar.worktime
  WorktimeService.class
  WorktimePersistenceService.class

I guess the first example could become confusing if the application grows and more and more logic is implemented. However, it appears to be easier to find the right place when the task is to "extend the persistent service layer to do something fancy". The second example can be easier extended without flooding packages with millions of classes.

Is there any best practice to choose between them? Or do you guys have any other idea of a package structure.

Upvotes: 0

Views: 1888

Answers (3)

Jens Schauder
Jens Schauder

Reputation: 81907

What is more important for your application?

Do you deploy the layers/types to different machines (or might want to do so in the future)?

Do different people work on different layers/types?

If so use layers/types to seperate packages.

If your application is a little larger, you probably want to use both, resulting in packages like

foo.bar.<layer>.<type>

or

foo.bar.<type>.<layer>

Upvotes: 1

Adriaan Koster
Adriaan Koster

Reputation: 16209

Usually there is a model package in which you put the types (Users, Payments and Worktimes in your example).

Next to the model package there are layer packages like presentation and service (I normally nest data access layers within the service package to encourage these layers to only be used from service implementations but that's up to you).

If the project is a bit bigger I split out the service layer into a separate module. If it is bigger still (or the domain model is large and complex) I also move the model package into a separate module, resulting in a three-module project: model, service and presentation.

If there are also multiple presentation channels (e.g. web application, REST service and dekstop client app) these can also be split out into separate modules.

Upvotes: -1

willome
willome

Reputation: 3132

As far as I am concerned I would package by layer AND type :

  • foo.bar.service.user.UserService
  • foo.bar.persistence.user.UserPersistence
  • And so on

For most of my projects I use maven and some multi modules :

  1. Domain Model (Model Objects)
  2. Persistence
  3. Service
  4. Applications

With this way, you could get different jars (or not if you have got only a simple project) and it is easier to retrieve the good place to extend/modify the existing sources.

Upvotes: 1

Related Questions