Chapter 6. The Business Tier

The word "enterprise" has a long and storied association with business. Adam Smith used the word in The Wealth of Nations back in 1776, and the antecedents go back another century. So, it's no wonder that when we talk about applications that support business processes we call them enterprise applications. The value of the application is bound up in the complexity of the business processes it represents, and in the amount of human effort the software removes from the equation. Virtually any large organization can benefit from properly deployed technology, from elementary schools to multinational corporations, and from volunteer groups to open source projects. In all of these situations, the value of the application depends on how well it supports the underlying business model.

This chapter introduces the business tier. We'll talk briefly about business models and business tier components, and draw some distinctions between them. The patterns in this chapter cover the domain model, which defines the entities that interact within your system, and the business logic, which defines the different actions that can be performed on the domain model. Our primary focus is on flexibility and extensibility: patterns that make it easier to balance the performance requirements of today with the inevitable change requests of tomorrow.

Business tiers are about complexity, memory, and scale. Business tiers are complex because they implement the rules the business must follow. The rules themselves can be simple ("mark each item shipped as removed from inventory," "when shipping to Massachusetts, add a 5% sales tax") but the interconnected system of rules can rapidly become more than any one person can easily handle. Memory, in the long-term recollection sense rather than the hardware sense, is important because businesses need to record every activity they participate in. Humans aren't well equipped to do this reliably, at least without tools and time. Finally, business tiers are about scale. Even if process and record-keeping activities are simple enough to be done by hand, repeating them several thousand times over the course of a day is costly, error-prone, and inflexible.^[1]

^[1] You can't run a query against a filing cabinet.

In the business tier, more than anywhere else, you have to keep an eye out for the unexpected. Creating domain models and business logic that meet the growth requirements of the environment presents a challenge to system architects. Even when the initial application requirements may not seem to impose much in terms of complexity, memory, and scale, change is inevitable. Business tiers require a substantial investment, so once created, they tend to be used and extended over the long haul. In fact, we rarely see successful enterprise applications enter an end-of-life stage. They're much more likely to be incorporated as a component of something else. Fifteen years from now there will be a vendor making a lot of money selling adapters to incorporate your old J2EE applications into whatever happens to be the new dominant environment. You'll often do the same thing yourself, integrating existing legacy systems into new J2EE frameworks.

A poorly implemented business tier imposes limitations on a system that fancy user interfaces can't overcome. On the other hand, a difficult user interface, or a middle tier that is slow or difficult to extend, prevents effective use of even the best-designed business and domain logic. A full J2EE application is an integrated whole, however compartmentalized it may be, that makes each tier more or less equally important. The art is in the interfaces that create the smoothly functioning whole. The business logic and domain model are the starting point that everything else grows out of.

Making the business tier a distinct, and somewhat isolated, section of the system helps us rope all these issues together. By implementing the business components separately from the presentation components, we can realize all the benefits we've been talking about over the last several chapters. The business tier presents interfaces to the presentation tier, exposing both business logic and possibly domain objects (we'll see in Chapter 7 why this isn't always necessary), but the business tier knows nothing of the presentation tier. It never generates HTML for web pages. In the same way, the object that represents a customer does not need to know how it is used; it only has to provide specific information on request.

While reading this chapter and those that follow, you may note that we harp quite a bit on the issue of network overhead. We do this not because we can't think of anything else to talk about, but because it's one of the most common performance killers in a distributed application, and J2EE applications are almost always distributed applications. Scale is very important. As we discussed in Chapters 1 and 5, any mid-size application (a few thousand users) should be able to support at least twice its current maximum load without substantial hardware or software upgrades, and should be further scalable with relatively minor additional effort.

This chapter, and the three that follow, are about implementing the model for your application—the M in MVC. This chapter focuses on the business tier itself: the representation of the business processes underlying an application. In the next chapter, we'll look at some of the mechanisms for exchanging data between the business tier and the presentation tier. Chapter 8 returns to implementation and discusses database patterns for implementing the domain objects, and Chapter 9 wraps up with a discussion of business tier interfaces: the frontends the business tier delivers to the presentation tier.