4.1 Benefits of Transparency

For most of this chapter, I'm going to explore the relationship between a service and a model. Your ultimate goal is to build a layer that's completely independent from the services that it uses. In particular, you want to keep all peripheral systems out of the domain model—persistence, transactions, security—everything. Why should the business domain model get such special treatment?

• Business models tend to change rapidly. Transparency lets you limit the changes to business logic.

• With transparency, you can limit changes to other parts of the system when your model changes.

• You can understand and maintain transparent models much more quickly than solutions with tighter coupling.

• By separating concerns of your layers, you can focus business, persistence, and security experts in the areas that make them the most productive.

You can also build completely generic services that know nothing in advance about the structure of your model. For example, a persistence service can save any generic Java object; a security service needs no additional code, but is based on configuration instead; a façade gets the capability to make a series of steps transactional just by adding a POJO to a container; a serialization service can turn any object into XML without knowing its structure in advance.

The core techniques in this chapter—reflection, code injection and other code generators—pack a punch, but they also add complexity and weight to your applications. My hope is that with a little supporting theory on your side, you'll be able to use these techniques to pry that ring out of your hand.

To be sure, none of these ideas are new, but I don't believe that they've received the weight that they deserve in the Java mainstream. I'll first talk about moving the control centers of the application to the appropriate place. Then, I'll give an overview of the tools that limit transparency, and wrap up with a few recommended tools to achieve it: code generation, reflection, and byte code enhancement, with an emphasis on reflection. If you're not used to coding this way, you'll find that it's going to warp your mind a little. Take heart. You've probably seen these techniques before, though you may need to rearrange the ideas a little. In the end, you'll find the ideas that percolated in the center of Smalltalk and around Java's perimeter have the power that you want, and even need.