POJOs

Plain Old Java Objects, a term coined by M. Fowler. He can explain the original inspiration best:

“I've come to the conclusion that people forget about regular Java objects because they haven't got a fancy name - so while preparing for a talk Rebecca Parsons, Josh Mackenzie and I gave them one: POJO (Plain Old Java Object). A POJO domain model is easier to put together, quick to build, can run and test outside of an EJB container, and isn't dependent on EJB (maybe that's why EJB vendors don't encourage you to use them.)” ~ Martin Fowler

On the plus side...
I'm not sure I use the term as he intended, so reader beware. Here are a few things I like:

• I like to think of my domain as a graph of active objects. Think of the Actor model in a distributed system rather than a bunch of static schema which are populated by access to a relational data base.
• I like to think I can pickel my graph and send it somewhere w/out losing the state of my computation.
• I like to make sure all external (file, db, etc) access takes care of their own cleanup -- especially exception handling. If exception handling needs to percolate accross major system boundaries, it should be done logically, not physically.
  
• Was the source of my object graph a web service? xml file? relational db? object db? word document? My clients should never know these deep, and often dark, secrets.
• I claim that EJB thinking is hard to eradicate. We need to raise the concept of Objects which send each other messages and behave in real time to the top level of the system.

Concerns
Many systems need to be ugly in their implementation because they need to support efficient transactions, lots of information, too many objects, etc. At some point, the core design of many systems must take these things into account; they cannot always be left to 'implementation'.
However, in many systems and system components, these issues are not serious.
For example, 8 gigs of ram on commoditiy servers is cheap. 2 gigs on a laptop is cheap. That is a lot of information. If my application has more information than that, perhaps my real problem is getting relevent information.
Techniques for using AOP to separate the concerns mentioned above is an area of active research and development. If these concerns are not pressing today, someone may solve them for me tomorrow.
Search
Search is an issue which is not straightforward if POJOs are cleanly separated from underlying database connections.

• RDBs do a lot of search well.
  
• RDBs make a lot of search effectivly impossible.
  

A useful implementation of a domain will probably contain serious infrastructure for search, sort, filter. Of course there is no need to start from scratch. Prevaylor and db40 are both useful starting points. Extensions to Java (Groovy) or languages which support closures directly (Ruby, Smalltalk, Lisp) are worth considering.