Praveen had a seemingly innocent question here and there were lots of good answers…

If we are following Agile Methodology (Scrum) & We are in Java/J2ee Domain,

What are the Best Practises & Design Principles need to be followed
while designing the applications.

Big question is an understatement… here’s what I would advise:

• Understand the business domain
  • because, if you get that wrong, it doesn’t much matter how well-crafted and well-tested your code is
  • Design using Separation of Concerns as the granddaddy of all patterns to sear into your brain.
  • Be sure you use a layered approach to your architecture — if I catch you putting SQL in your javascript, I’ll come over there and stab you in the toe
  • Design in the Large to avoid excessive dependencies
  • Design in the small to adhere to all those good practices like SOLID
  • Consider looking into the Domain Neutral Component — within which a shockingly huge number of domains tend to fit.
• Architect and build the application in a highly consistent manner — much like Rails enforces.
  • If you have a dozen domain items that need the same sort of treatment from persistence to UI, please don’t get creative and do persistence 5 different ways.
  • Pick one and stick with it for the sake of consistency!
  • I’d rather a consistent implementation that is mediocre, than one with 5 different approaches (one stellar, one horrid, and the rest mediocre). Why you might ask? Because it is easier to refactor when things are consistent 🙂
• And, of course, apply an agile process…
  • Involve a customer/proxy to ensure you understand the requirements from the business perspective, do not rely on documents — but if you must, then you need to exaggerate the agile process and make it more granular. That is, to compensate for the likelihood that the written word is ambiguous, you need to show small steps of progress on a feature and get rapid feedback to ensure you are not mis-interpreting the requirements doc.
  • Build a vertical slice of your design to prove it out and to serve as a model for how you will work on your app
  • If you have stringent performance needs, prove them out early
  • Show working code early and often
  • Get yourselves set up on an automated build
  • Try to build out the features using something like BDD or TDD
• General
  • Be patient with your learning
  • Be impatient to see results, don’t let any team member or task go dark for more than a couple of days
  • Create the lightest-weight process possible
  • Don’t do anything to excess without frequent feedback
  • Always foster a team attitude to question everything with boldness — including my advice

Hope that helps