Some wise words on design - I recently was listening to a presentation in InfoQ on design principles of successful large scale enterprise financial application based on Spring & Hibernate. I noted some points while listening to that. Although these are well known established principles I thought it's easier to refer & document when ever we need to come up new design document.

• Minimize data movement
• Task Parallel execution where ever possible
  
• Physically partition of data
• Optimized reads & writes of volatile data
• Minimize contention -- Different connection pooling
• Asynchronous Decoupling
• Complete Business Logic performed by data
• Caching frequently accessed data

Like all popular scalable architecture (eBay, Yahoo) the transaction (distrubuted) & state management were simple (stateless & transactionless for 90% of operations)
JDBCTemplate - fantastic example of Dependency injection
Spring promotes good design - modularity, loose coupling separation of concerns
Testability provides better confidence for refactoring
Hibernate promotes domain driven design - 2'nd level caching is gr8

Contents of design document can be divided into following categories:

• Architectural review
• Jumpstart programs
• Deployment strategy
• Platform change
• Proof of concept
• Performance tuning
• Development

Capacity Planning questions:

• How much memory footprint the application requires
• How many threads the application components need
• How many connections each application has to handle
• How many system resources like file handles are required
• How much parallelism is attainable in a single process
• How many CPUs can be leveraged at the same time from within the same hardware
• What are the synchronization primitives available in case of multiple processes and nodes
• How we coordinate shared accesses and leases
• The allowable number of nodes that a unit of application job can cross, taking into consideration the performance criterion

I also listened to Joshua Bloch's presentation on design guide lines, Joshua Bloch is currently Java Architect at Google & has great influence on Java's future. He also influenced (JDK5) & wrote many JDK classes as distinguished Engineer at Sun. His assertions carries lot of weight.
Importance of API design for internal and external use.

• Public APIs are forever - one chance to get it right
• Good code is modular–each module has an API
• Thinking in terms of APIs improves code quality
• Easy to use, even without documentation
• Don’t let implementation details “leak” into API
• Make classes and members as private as possible

I guess the most important one was "when in doubt, don't provide the API, leave it".

"There's a natural law in programming language and API design : as backwards compatibility increases, elegance decreases." - Bill Venners
So be minimalist, because of the compatibility requirement, it's much easier to put things in than to take them out. So don't add anything to the API that you're not sure you need