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

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.

Solution 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.

Solution 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.

Solution 3

Take a look at Robert Martin's (aka Uncle Bob) Clean Architecture. Here's a quick overview. Using this approach, you'll be able to defer details like Spring or Hibernate to a later time and focus more on the business logic. Or even migrate from Spring to Java EE without touching your business and application logic. You'll also get a testable application that complies with the SOLID principles, without too much additional effort.

I've just created an application this way and I must say I'm very happy with it. I could easily port it to a desktop or mobile application, or swap out the storage module. Details depending on policy goes a long way. It also promotes thinking in an API kind of way and, when applied correctly, making your modules very reusable.

Martin goes as far as saying details like frameworks are annoying and not part of your architecture. I do think they belong to architecture, but just at a different level. Often times you do want to include frameworks at an early stage to be able to produce a thin slice of a working application to demo to your users. Or when you know your frameworks in advance and there is no discussion about them, like in my case. But you could regard it as separate software architectures, when combined together create your application architecture.

Solution 4

Peruse the Agile Modeling site which pushes for "just enough" modeling. They have some great guidelines including a full "agile modeling process" from requirements gathering to design/development.

http://www.agilemodeling.com/

http://www.agilemodeling.com/essays/amdd.htm

http://www.agilemodeling.com/essays/agileArchitecture.htm

http://www.agilemodeling.com/essays/agileAnalysis.htm

http://www.agilemodeling.com/essays/agileDesign.htm

As for tools, I love Visual Paradigm. It's relatively inexpensive (compared to other tools). There are a variety of free modeling tools (google is your friend), but none compare to Visual Paradigm, and for bit that it costs, it's well worth it. If my employer didn't pony up the cash for it, I would buy it myself... :)

View more solutions

Comments

[Senthil]

In your past 5yrs experience, Any of the project design documents given for you to develop or any discussion you had with Architect? Bascially check on any Software Design/Architecture book for basic understanding. You need to start with requirements to use case scenarios, then sequence diagram, system architecture design, component diagram, class diagram and database design like that. Depend on practice in your workplace, you may need to some extra documents or less. but, this is basic minimum set.

[ashishjmeshram]

I have not had any design documents in the projects I have worked so far :-(. Hence it is looking more tough for me.

[BertNase]

Maybe you also have alook at Enterprise Architect (sparxsystems.com.au) for modelling - it is far the best diagramming tool I know (from the usability POV). There is a time-limited-full-featured demo available and the license fees are also affordable.

[squawknull]

I like EA too. I just like VP better :) Both are great tools at approximately the same price point. Quite frankly, I think both are far better than most of the tools that are far more expensive.

[Ramon Chiara]

Dormouse, I really would like to talk to you about Clean Architecure, since you've got it for real... I'm paralised in best way to implement the input and output model/ports. I've tried a simple spike here: github.com/ramonchiara/CleanArchSpike. Could you please give a feedback? Is it allowed to publish our personal contact here?

[Dormouse]

I have posted a comment on your website :)

[DB5]

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes.

[Amritendu De]

Revised the post to include more meat

[Raúl]

Thanks Kunal, its quite impressive. If possible, kindly update it with any useful findings you might have since last update. rgds.

[Yogendra]

I would also suggest having a plan to introduce performance testing / tuning from very early on in the cycle. Early introduction of Performance testing into Design and Development gives enough time to go and change if anything is required.

[Tejas C]

care to comment for down voting please?

[Filou]

Clean Architecture Example: Code for an Onion Architecture is a blog post by Mark Paluch about the clean architecture. It includes a link to a github repository for a closer look at a sample implementation.

[Dormouse]

This is an example by Mattia Battiston. It contains a detailed explanation presentation and code example: slideshare.net/mattiabattiston/…

[Radiodef]

The downvote is probably because answers which are only a link to elsewhere are generally frowned upon. meta.stackexchange.com/questions/8231/…