How to structure applications as multiple projects and how to name packages in Java?

advertisements

I would like to know how you set up your projects in Java. For example, in my current work project, a six year old J2EE app with approximately 2 million LoC, we only have one project in Eclipse. The package structure is split into tiers and then domains, so it follows guidelines from Sun/Oracle. A huge ant-script is building different jars out of this one source-folder

Personally I think it would be better to have multiple projects, at least for each tier. Recently I was playing around with a project structure like this:

  • Domainproject (contains only annotated pojos, needed by all other projects)
  • Datalayer (only persistence)
  • Businesslogic (services)
  • Presenter
  • View

This way, it should be easier to exchange components. In addition, when using a build tool like Maven I can have everything in a repository so when I am only working on the frontend I can get the rest as a dependency in my classpath.

Does this makes sense to you? Do you use different approaches and how do they look like?

Furthermore I am struggling how to name my packages/projects correctly. Right now, the above project-structure reflects in the names of the packages, eg. de.myapp.view and it continues with some technical subfolders like internal or interfaces. What I am missing here, and I don't know how to do this properly, is the distinction to a certain domain. When the project gets bigger it would be nice to recognise a particular domain but also the technical details to navigate more easily within the project.

This leads to my second question: how do you name your projects and packages?


Your approach makes sense. I would normally decompose into a model (shared), numerous libraries, and then the applications consuming that code and the GUIs - all as separate projects. I tend to follow the Pragmatic Programmers' dictum of build toolsets, not applications. That way you can reassemble your components in lots of different ways.

Each library/application would be its own project, with unit/functional tests and a deliverable (in your case, a Maven artifact that you can store and version appropriately).

The only headache is managing the interfaces and linking between these components. An effective integration test environment is key here.