I have Web application project that uses Struts and Hibernate. It is based on the MVC design pattern. The project contains the packages "bo" for business objects, "dao" for the data access objects, "persistence" for the hibernate reverse engineered objects, struts.action for the action classes, and the struts.forms for the form classes. We are using an abstract database model so are database tables are party_type, party, party_attribute, party_attribute_values, role_type, role, role_attribute, role_attribute_values, party_role_relationship_type, party_role_relationships, role_relationship_type, role_relationships. So If I add a new customer it would be a party of type customer and have the attributes for the customer party type would be entered for this customer. The user interfaces for each type of role and or party would be specific to that type of party and use the same under lying database tables to store the different information. Our boss would like us to take the one big project that has been created and create multiple projects for each type of user interface that is needed (customer maintenance, employee mainteance, product maintenance) He would also like us to break up the low level classes for the bo, dao, and persistence objects into multiple jar files instead of having just one. His concerns are being able to redeploy different parts of the system without affecting other parts of the system or having to take the whole system down. I could see creating separate projects for the GUI par and creating separate war files but since the under lying business logic and data base is abstract, breaking these pieces into multiple jars does not seem realistic since there is so much dependence (foreign key constraints). I have not been able to find any material on how projects to be organized (as one large project or many smaller ones).
One project where I work right now was split into lots of sub-projects and lots of separate jars as you describe. For many reasons we are now regretting that decision.
Splitting a system into separate projects can make it very clumsy to set up a new development environment, either for a new developer, for a replacement workstation, or just when working on a code branch.
Splitting a system into separate jars is effectively setting the architecture in stone. It becomes hard to refactor and simplify across the boundary between jars, and this makes for a system which grows more complex and "bloaty" over time.
Managing all these separate artefacts can also cause build problems. Not only will it take much longer to build a system, but the more artefacts there are, the more risk is introduced into deployment. Every component and config file potentially needs to contain its own version information, and testing needs to involve every likely combination of versions of every component. This can rapidly lead to an effectively un-testable system and thus introduce problems on the live environment.
In short, working with a single project which produces a single artefact is so much simpler, easier and quicker to work with, and less risky to deploy that I would only consider splitting it where there is no other way.
Please try hard to dissuade your "boss" from this dangerous approach!
Originally posted by David Kirvan: His concerns are being able to redeploy different parts of the system without affecting other parts of the system or having to take the whole system down.
This sounds like a configuration management nightmare. If you deploy little pieces independently, how do you know what is deployed and that it works together?
I'm actually somewhere in the middle of your boss and Frank for three reasons. 1) I like having some different projects, but for logically different layers. For example, I like having the back end code in a different project than the front in code. It makes reuse easier if the code is used by multiple parties. How many divisions make sense varies based on the application, layers and reuse requirements (if any.) 2) I like having the architecture more explicit. I t reinforces boundaries between layers. 3) I consider the deployment package separate. No matter how many projects I have, I deploy one ear. It may contain multiple wars and jars, but it's one thing.