This article has a long introduction in order to finally explain the abbreviation PUFO....
In my work as an consultant I often have to explain to people the difference between domain classes and (let's for now say) "technical classes". I often stress the fact that we should spend as little time as possible on these technical classes. The reason for this is that we tell the world we automate business processes. Then when we get to work we seem to be busy only with technical "stuff". This is becoming less and less due to frameworks, but go back 4 years and probably your database-access logic comprised 60% of your code (just count the lines of SQL related code compared to the rest). Then throw in transactions, security, concurrency and you probably ended up spending around 80% of your time on coding technical "stuff", and only 20% went into the reason you are getting paid: the business rules and other functional aspects of the system. I have never seen a business process with the word "database" in it, have you (well, at Oracle perhaps: "sell database license")? Just to be clear: a database in an OO system is used to address a quality attribute of the system that ensures information is not lost after a power failure. In addition, the cost of memory is still higher than that of hard drive space, so it makes more sense to store on disk.
I often use the diagram below to illustrate the difference in functionality of the system:
As the diagram illustrates, a "software developer" in the role of "software designer" is responsible for the functional aspects of the system (design and implementation). He or she will do so in the form of a domain model (with domain classes, etc). The quality aspects of the system are addressed by the software architect. The idea is that we spend little to no time on this, hence the birth of frameworks such as Java EE, JPA, MyBatis etc. You, as a developer of course, still need to implement code. It is this code which is often managed by a IoC container such as Spring. A good name for these non-domain classes could therefore be the "unpaid classes", as we should not be paid when we work on them.
Craig Larman in his book "Applying UML and Patterns" (the best book to get introduced to OO -- wish I had it back in the eighties) lists different patterns under "General Responsibility Assignment Software Patterns/Principles" (GRASP). One of them is coined "Pure Fabrication", meaning a class which is not an abstraction of a domain concept. I have always been very pleased with a name for these classes (other then "technical classes" or the likes)
In Java (and other technical areas) we love abbreviations. One I like in particular was POJO (plain old java objects). Unfortunately, this has been taken over by the vendors (everything is now a POJO, so there is no longer a need to differentiate between them).
Along those lines, a brilliant abbreviation I would like to introduce is PUFO: "Pure Fabricated Object"... pronounced like PJU-FO (with a strong emphasis on the "puke" sound at the beginning to illustrate that we should work as little as possible on these classes).