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.