How to structure applications as multiple projects an name the packages in Java

Question

Hello Everyone

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 projects-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 and when using a build tool like Maven I can have everything in a repository so when only working on the frontend I can get the rest as a dependecy in my classpath.

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

Furthermore I am struggeling 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 dont 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?

Answer 1

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.

Answer 2

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

For project names i prefer an internal name like Longhorn=WinVista. This name never changes (like my kids names). So marketing, etc can register any name, rebrand, etc.

Packages are a question of (personal) preferences and style. And normally the senior programmer decides the structure. Of course there are some "standards" as "gui" for UI classes, "util","misc", "impl" for interface implementations, "domain" for domain object classes, etc that you should use consistently and express your style.