All Java Architects: Read This

 have a couple of quick notes for any aspiring java architects. Please read them carefully and think about them.

Adding layers is BAD

In general, you don't need extra layers until you need them. At that point, add a new layer (but only in necessary places). Create "standard" layers just adds complexity, makes maintenance more expensive, and ultimately fosters copy/paste coding and discourages developers from thinking about what they're doing. An example of a good time to add a layer is when you need to hide complicated operations behind a facade because low level database transaction management is being done in the same place as the code that determines which screen should be displayed next. Too many developers heard "layers add flexibility/scaleability/whatever" and started adding layers to every situation that has an arbitrary division of responsibility... I've worked on systems where adding a table column to be displayed in a CRUD application required changing upwards of 10 different classes... this is a maintenance nightmare.

Interfaces have a special purpose, you don't need them for everything

Not every class needs an interface... They should be reserved for situations where an interface is useful and not just another unnecessary ceremony that developers will mindlessly follow "because that's the way we do it here". A good example of an interface would be something like "Nameable or Labelable". These are often contexts that systems need when rendering information ('cause toString() often won't cut it). The key point is that there will be many classes (at least more than one) that will implement the same interface in the system at the same time. If you try to hide an implementation behind an interface with the idea that the implementation might change in the future... Just use a concrete class and change the dag gone implementation when you need to change it. Don't force every update every developer makes for the next 6 years be TWICE as much effort...

Beware of one size fit's all solutions

Don't build the titanic when all you need is a rowboat. I've seen monster frameworks grow because of one tiny edge case. Instead of treating the single edge case as an outlier and walling of that portion of code from everything else, may architects make the mistake of trying to accomodate the edge case in EVERY part of the system. In addition to extra layers and extra interfaces, I've seen systems that generate javascript web service code, soap stubs, extra java classes to handle serialization, and any other number of overcomplicated plumbing... just because one or two calls in the system needed to be remote.

The short version is, don't overcomplicate your solutions and don't start adding code you don't need ahead of time. You'll be carrying that code on your back for every step you take and need to make sure you don't burn out hauling a bunch of unnecessary baggage.