How to Design and Architect a Java/Java EE web application? [closed]

Question

I am java developer with almost 5 years of experience on Struts, Spring and Hibernate.

We have a new project coming up in few days. We have the complete requirements with us and we will be doing this project using Spring MVC, Spring and the Hibernate.

I have been asked to design and architect the entire web application. Designing and creating an Architect is something which I have not done till now in my career. And I don't know how do I go about this and where to start, what tools to use and so on. I don't know even the A,B,C's of design and architecture.

You may be wondering why I was even I asked to do this at first place. The thing is I was given an opportunity to do this and at every stage I will be monitored and I will have my seniors reviewing the design.

So any suggestion, ideas and steps to start and go ahead are welcome.

Answer 1

I can add my 2 cents from my own experiences (although its more of a compilation of development best practises, you might find it useful to keep them in mind while designing your application):

• There is no one-size-fits-all design
• Try to keep application as light weight as possible.
• Use Maven/Gradle to manage dependencies
  • Don't rely excessively on IDE. Make sure your project builds without IDE (If you are using maven/gradle, It will :) Try to open you project with IDEA, Netbeans and Eclipse.
• For the technologies mentioned above, appfuse makes a good starting point.
• Design your database/entities first
• Use libraries sensibly and judiciously. Do NOT overuse them.
• Dont forget to write JUnit/TestNG (at least for service layer)
• Test application on all major browsers (not just your favorite one :)
• Determine how many total users and how many concurrent users your web app will have.
  
  • Then decide whether you need caching or not.
  • you will use app server clustering or not.
• Select the application server based on its capabilities and more importantly 'your needs'
  • Tomcat / Jetty are absolutely fine for most of the cases
• Avoid using any app-server specific api
• Use JPA interfaces/annotations even if using hibernate as JPA implementation
• Be extra cautious while mapping relationships in entities. Decide which properties and relationships will load lazily and which will load eagerly
• Keep application security in mind while designing the app. Spring security is excellent choice.
• Never abuse HttpSession. Dont store too much in it.
• Keep entities Serializable. Enforce developers to use toString(), hashCode() and equals()
• Dont Forget to use version controlling from Day 1
• Dont just assume that spring/hibernate/spring-mvc will be best choice for you. create small proof of concepts with atleast 3 to 4 options.
• Try to automate integration/build/deploy with CI tools like Jenkins
• Check and Tune SQL generated by Hibernate (time to time)
• Do not let business logic creep into view layer. Hate jsp scriptlets? Consider Velocity/Freemarker. JSP is not the only option.
• externalize the environment specific configuration by using Spring's PropertyPlaceholderConfigurator.
• If possible, try to integrate with existing User Authentication mechanism (Like LDAP/ OpenID) rather than writing your own. This will save you from reinventing the wheel and your users from remembering yet another set of username and password.

Answer 2

There are several things you'll need for architecture design documents. Not an easy task but props on taking the opportunity. Since this is such a large question, hopefully these links can get you started and you can refine questions after getting your feet wet.

Methodology

The methodology you use will affect what tasks you take on first. Waterfall is a popular but outdated methodology. A newer methodology is Agile that has several faces. My favorite is Scrum Agile for developing software of any size.

Diagrams

Diagrams are one of the most powerful ways to represent the system as a whole and as individual components. The type of diagrams you create depend on the system. There are usually a Structure Diagrams, Behavior Diagrams, Interaction Diagrams and tons of others. These diagrams show the pieces of the system as a whole, each components physical layout and/or logical layout, communication flow, procedure flow, etc..

Documentation

Documentation is just like it sounds, documents and documents that have Project Descriptions, Scope, User Cases, Sequence Diagrams, and any other document that describes the project or pieces of the project.