In case you haven’t realized it, building computer systems is hard. As the complexity of the system gets greater, the task of building the software gets exponentially harder. As in any profession, we can progress only by learning, both from our mistakes and from our successes. This book represents some of this learning written in a form that I hope will help you to learn these lessons quicker than I did, or to communicate to others more effectively than I did before I boiled these patterns down.
In this introduction I want to set the scope of the book and provide some of the background that will underpin its ideas.
The software industry delights in taking words and stretching them into a myriad of subtly contradictory meanings. One of the biggest sufferers is “architecture.” I tend to look at “architecture” as one of those impressive-sounding words, used primarily to indicate that we’re talking something that’s important. But I’m pragmatic enough not to let my cynicism get in the way of attracting people to my book. :-)
“Architecture” is a term that lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change. It’s also increasingly realized that there isn’t just one way to state a system’s architecture; rather, there are multiple architectures in a system, and the view of what is architecturally significant is one that can change over a system’s lifetime.
From time to time Ralph Johnson has a truly remarkable posting on a mailing list, and he did one on architecture just as I was finishing the draft of this book. In this posting he brought out the point that architecture is a subjective thing, a shared understanding of a system’s design by the expert developers on a project. Commonly this shared understanding is in the form of the major components of the system and how they interact. It’s also about decisions, in that it’s the decisions that developers wish they could get right early on because they’re perceived as hard to change. The subjectivity comes in here as well because, if you find that something is easier to change than you once thought, then it’s no longer architectural. In the end architecture boils down to the important stuff—whatever that is.
In this book I present my perception of the major parts of an enterprise application and of the decisions I wish I could get right early on. The architectural pattern I like the most is that of layers, which I describe more in Chapter 1. This book is thus about how you decompose an enterprise application into layers and how these layers work together. Most nontrivial enterprise applications use a layered architecture of some form, but in some situations other approaches, such as pipes and filters, are valuable. I don’t go into those situations, focusing instead on the context of a layered architecture because it’s the most widely useful.
Some of the patterns in this book can reasonably be called architectural, in that they represent significant decisions about these parts; others are more about design and help you to realize that architecture. I don’t make any strong attempt to separate the two, since what is architectural or not is so subjective.
Lots of people write computer software, and we call all of it software development. However, there are distinct kinds of software out there, each of which has its own challenges and complexities. This comes out when I talk with some of my friends in the telecom field. In some ways enterprise applications are much easier than telecoms software—we don’t have very hard multithreading problems, and we don’t have hardware and software integration. But in other ways it’s much tougher. Enterprise applications often have complex data—and lots of it—to work on, together with business rules that fail all tests of logical reasoning. Although some techniques and patterns are relevant for all kinds of software, many are relevant for only one particular branch.
In my career I’ve concentrated on enterprise applications, so my patterns here are all about that. (Other terms for enterprise applications include “information systems” or, for those with a long memory, “data processing.”) But what do I mean by the term “enterprise application”? I can’t give a precise definition, but I can give some indication of my meaning.
I’ll start with examples. Enterprise applications include payroll, patient records, shipping tracking, cost analysis, credit scoring, insurance, supply chain, accounting, customer service, and foreign exchange trading. Enterprise applications don’t include automobile fuel injection, word processors, elevator controllers, chemical plant controllers, telephone switches, operating systems, compilers, and games.
Enterprise applications usually involve persistent data. The data is persistent because it needs to be around between multiple runs of the program—indeed, it usually needs to persist for several years. Also during this time there will be many changes in the programs that use it. It will often outlast the hardware that originally created much of it, and outlast operating systems and compilers. During that time there’ll be many changes to the structure of the data in order to store new pieces of information without disturbing the old pieces. Even if there’s a fundamental change and the company installs a completely new application to handle a job, the data has to be migrated to the new application.
There’s usually a lot of data—a moderate system will have over 1 GB of data organized in tens of millions of records—so much that managing it is a major part of the system. Older systems used indexed file structures such as IBM’s VSAM and ISAM. Modern systems usually use databases, mostly relational databases. The design and feeding of these databases has turned into a subprofession of its own.
Usually many people access data concurrently. For many systems this may be less than a hundred people, but for Web-based systems that talk over the Internet this goes up by orders of magnitude. With so many people there are definite issues in ensuring that all of them can access the system properly. But even without that many people, there are still problems in making sure that two people don’t access the same data at the same time in a way that causes errors. Transaction manager tools handle some of this burden, but often it’s impossible to hide this from application developers.
With so much data, there’s usually a lot of user interface screens to handle it. It’s not unusual to have hundreds of distinct screens. Users of enterprise applications vary from occasional to regular, and normally they will have little technical expertise. Thus, the data has to be presented lots of different ways for different purposes. Systems often have a lot of batch processing, which is easy to forget when focusing on use cases that stress user interaction.
Enterprise applications rarely live on an island. Usually they need to integrate with other enterprise applications scattered around the enterprise. The various systems are built at different times with different technologies, and even the collaboration mechanisms will be different: COBOL data files, CORBA, messaging systems. Every so often the enterprise will try to integrate its different systems using a common communication technology. Of course, it hardly ever finishes the job, so there are several different unified integration schemes in place at once. This gets even worse as businesses seek to integrate with their business partners as well.
Even if a company unifies the technology for integration, they run into problems with differences in business process and conceptual dissonance with the data. One division of the company may think a customer is someone with whom it has a current agreement; another division also counts those that had a contract but don’t any longer; another counts product sales but not service sales. That may sound easy to sort out, but when you have hundreds of records in which every field can have a subtly different meaning, the sheer size of the problem becomes a challenge—even if the only person who knows what the field really means is still with the company. (And, of course, all of this changes without warning.) As a result, data has to be constantly read, munged, and written in all sorts of different syntactic and semantic formats.
Then there’s the matter of what comes under the term “business logic.” I find this a curious term because there are few things that are less logical than business logic. When you build an operating system you strive to keep the whole thing logical. But business rules are just given to you, and without major political effort there’s nothing you can do to change them. You have to deal with a haphazard array of strange conditions that often interact with each other in surprising ways. Of course, they got that way for a reason: Some salesman negotiated to have a certain yearly payment two days later than usual because that fit with his customer’s accounting cycle and thus won a couple of million dollars in business. A few thousand of these one-off special cases is what leads to the complex business “illogic” that makes business software so difficult. In this situation you have to organize the business logic as effectively as you can, because the only certain thing is that the logic will change over time.
For some people the term “enterprise application” implies a large system. However, it’s important to remember that not all enterprise applications are large, even though they can provide a lot of value to the enterprise. Many people assume that, since small systems aren’t large, they aren’t worth bothering with, and to some degree there’s merit here. If a small system fails, it usually makes less noise than a big system. Still, I think such thinking tends to shortchange the cumulative effect of many small projects. If you can do things that improve small projects, then that cumulative effect can be very significant on an enterprise, particularly since small projects often have disproportionate value. Indeed, one of the best things you can do is turn a large project into a small one by simplifying its architecture and process.
When we discuss how to design enterprise applications, and what patterns to use, it’s important to realize that enterprise applications are all different and that different problems lead to different ways of doing things. I have a set of alarm bells that go off when people say, “Always do this.” For me much of the challenge (and interest) in design is in knowing about alternatives and judging the trade-offs of using one alternative over another. There is a large space of alternatives to choose from, but here I’ll pick three points on this very big plane.
Consider a B2C (business to customer) online retailer: People browse and—with luck and a shopping cart—buy. For such a system we need to be able to handle a very high volume of users, so our solution needs to be not only reasonably efficient in terms of resources used but also scalable so that you can increase the load by adding more hardware. The domain logic for such an application can be pretty straightforward: order capturing, some relatively simple pricing and shipping calculations, and shipment notification. We want anyone to be able access the system easily, so that implies a pretty generic Web presentation that can be used with the widest possible range of browsers. Data source includes a database for holding orders and perhaps some communication with an inventory system to help with availability and delivery information.
Contrast this with a system that automates the processing of leasing agreements. In some ways this is a much simpler system than the B2C retailer’s because there are many fewer users—no more than a hundred or so at one time. Where it’s more complicated is in the business logic. Calculating monthly bills on a lease, handling events such as early returns and late payments, and validating data as a lease is booked are all complicated tasks, since much of the leasing industry’s competition comes in the form of little variations over deals done in the past. A complex business domain such as this is challenging because the rules are so arbitrary.
Such a system also has more complexity in the user interface (UI). At the least this means a much more involved HTML interface with more, and more complex, screens. Often these systems have UI demands that lead users to want a more sophisticated presentation than a HTML front end allows, so a more conventional rich-client interface is needed. A more complex user interaction also leads to more complicated transaction behavior: Booking a lease may take an hour or two, during which time the user is in a logical transaction. We also see a complex database schema with perhaps two hundred tables and connections to packages for asset valuation and pricing.
A third example point is a simple expense-tracking system for a small company. Such a system has few users and simple logic and can easily be made accessible across the company with an HTML presentation. The only data source is a few tables in a database. As simple as it is, a system like this is not devoid of a challenge. You have to build it very quickly and you have to bear in mind that it may grow as people want to calculate reimbursement checks, feed them into the payroll system, understand tax implications, provide reports for the CFO, tie into airline reservation Web services, and so on. Trying to use the architecture for either of the other two example systems will slow down the development of this one. If a system has business benefits (as all enterprise applications should), delaying those benefits costs money. However, you don’t want to make decisions now that will hamper future growth. But if you add flexibility now and get it wrong, the complexity added for flexibility’s sake may actually make it harder to evolve in the future and may delay deployment and thus delay the benefit. Although such systems may be small, most enterprises have a lot of them so the cumulative effect of an inappropriate architecture can be significant.
Each of these three enterprise application examples has difficulties, and they are different difficulties. As a result you can’t come up with a single architecture that will be right for all three. Choosing an architecture means that you have to understand the particular problems of your system and choose an appropriate design based on that understanding. That’s why in this book I don’t give a single solution for your enterprise needs. Instead, many of the patterns are about choices and alternatives. Even when you choose a particular pattern, you’ll have to modify it to meet your demands. You can’t build enterprise software without thinking, and all any book can do is give you more information to base your decisions on.
If this applies to patterns, it also applies to tools. Although it obviously makes sense to pick as small a set of tools as you can to develop applications, you also have to recognize that different tools are best for different purposes. Beware of using a tool that is really suited for a different kind of application—it may hinder more than help.
Many architectural decisions are about performance. For most performance issues I prefer to get a system up and running, instrument it, and then use a disciplined optimization process based on measurement. However, some architectural decisions affect performance in a way that’s difficult to fix with later optimization. And even when it is easy to fix, people involved in the project worry about these decisions early.
It’s always difficult to talk about performance in a book such as this. The reason that it’s so difficult is that any advice about performance should not be treated as fact until it’s measured on your configuration. Too often I’ve seen designs used or rejected because of performance considerations, which turn out to be bogus once somebody actually does some measurements on the real setup used for the application.
I give a few guidelines in this book, including minimizing remote calls, which has been good performance advice for quite a while. Even so, you should verify every tip by measuring on your application. Similarly there are several occasions where code examples in this book sacrifice performance for understandability. Again it’s up to you to apply the optimizations for your environment. Whenever you do a performance optimization, however, you must measure both before and after, otherwise, you may just be making your code harder to read.
There’s an important corollary to this: A significant change in configuration may invalidate any facts about performance. Thus, if you upgrade to a new version of your virtual machine, hardware, database, or almost anything else, you must redo your performance optimizations and make sure they’re still helping. In many cases a new configuration can change things. Indeed, you may find that an optimization you did in the past to improve performance actually hurts performance in the new environment.
Another problem with talking about performance is the fact that many terms are used in an inconsistent way. The most noted victim of this is “scalability,” which is regularly used to mean half a dozen different things. Here are the terms I use.
Response time is the amount of time it takes for the system to process a request from the outside. This may be a UI action, such as pressing a button, or a server API call.
Responsiveness is about how quickly the system acknowledges a request as opposed to processing it. This is important in many systems because users may become frustrated if a system has low responsiveness, even if its response time is good. If your system waits during the whole request, then your responsiveness and response time are the same. However, if you indicate that you’ve received the request before you complete, then your responsiveness is better. Providing a progress bar during a file copy improves the responsiveness of your user interface, even though it doesn’t improve response time.
Latency is the minimum time required to get any form of response, even if the work to be done is nonexistent. It’s usually the big issue in remote systems. If I ask a program to do nothing, but to tell me when it’s done doing nothing, then I should get an almost instantaneous response if the program runs on my laptop. However, if the program runs on a remote computer, I may get a few seconds just because of the time taken for the request and response to make their way across the wire. As an application developer, I can usually do nothing to improve latency. Latency is also the reason why you should minimize remote calls.
Throughput is how much stuff you can do in a given amount of time. If you’re timing the copying of a file, throughput might be measured in bytes per second. For enterprise applications a typical measure is transactions per second (tps), but the problem is that this depends on the complexity of your transaction. For your particular system you should pick a common set of transactions.
In this terminology performance is either throughput or response time—whichever matters more to you. It can sometimes be difficult to talk about performance when a technique improves throughput but decreases response time, so it’s best to use the more precise term. From a user’s perspective responsiveness may be more important than response time, so improving responsiveness at a cost of response time or throughput will increase performance.
Load is a statement of how much stress a system is under, which might be measured in how many users are currently connected to it. The load is usually a context for some other measurement, such as a response time. Thus, you may say that the response time for some request is 0.5 seconds with 10 users and 2 seconds with 20 users.
Load sensitivity is an expression of how the response time varies with the load. Let’s say that system A has a response time of 0.5 seconds for 10 through 20 users and system B has a response time of 0.2 seconds for 10 users that rises to 2 seconds for 20 users. In this case system A has a lower load sensitivity than system B. We might also use the term degradation to say that system B degrades more than system A.
Efficiency is performance divided by resources. A system that gets 30 tps on two CPUs is more efficient than a system that gets 40 tps on four identical CPUs.
The capacity of a system is an indication of maximum effective throughput or load. This might be an absolute maximum or a point at which the performance dips below an acceptable threshold.
Scalability is a measure of how adding resources (usually hardware) affects performance. A scalable system is one that allows you to add hardware and get a commensurate performance improvement, such as doubling how many servers you have to double your throughput. Vertical scalability, or scaling up, means adding more power to a single server, such as more memory. Horizontal scalability, or scaling out, means adding more servers.
The problem here is that design decisions don’t affect all of these performance factors equally. Say we have two software systems running on a server: Swordfish’s capacity is 20 tps while Camel’s capacity is 40 tps. Which has better performance? Which is more scalable? We can’t answer the scalability question from this data, and we can only say that Camel is more efficient on a single server. If we add another server, we notice that Swordfish now handles 35 tps and Camel handles 50 tps. Camel’s capacity is still better, but Swordfish looks like it may scale out better. If we continue adding servers we’ll discover that Swordfish gets 15 tps per extra server and Camel gets 10. Given this data we can say that Swordfish has better horizontal scalability, even though Camel is more efficient for less than five servers.
When building enterprise systems, it often makes sense to build for hardware scalability rather than capacity or even efficiency. Scalability gives you the option of better performance if you need it. Scalability can also be easier to do. Often designers do complicated things that improve the capacity on a particular hardware platform when it might actually be cheaper to buy more hardware. If Camel has a greater cost than Swordfish, and that greater cost is equivalent to a couple of servers, then Swordfish ends up being cheaper even if you only need 40 tps. It’s fashionable to complain about having to rely on better hardware to make our software run properly, and I join this choir whenever I have to upgrade my laptop just to handle the latest version of Word. But newer hardware is often cheaper than making software run on less powerful systems. Similarly, adding more servers is often cheaper than adding more programmers—providing that a system is scalable.
Patterns have been around for a long time, so part of me doesn’t want to regurgitate their history yet another time. Still, this is an opportunity for me to provide my view of patterns and what makes them a worthwhile approach to describing design.
There’s no generally accepted definition of a pattern, but perhaps the best place to start is Christopher Alexander, an inspiration for many pattern enthusiasts: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” [Alexander et al.]. Alexander is an architect, so he was talking about buildings, but the definition works pretty nicely for software as well. The focus of the pattern is a particular solution, one that’s both common and effective in dealing with one or more recurring problems. Another way of looking at it is that a pattern is a chunk of advice and the art of creating patterns is to divide up many pieces of advice into relatively independent chunks so that you can refer to them and discuss them more or less separately.
A key part of patterns is that they’re rooted in practice. You find patterns by looking at what people do, observing things that work, and then looking for the “core of the solution.” It isn’t an easy process, but once you’ve found some good patterns they become a valuable thing. For me their value lies in being able to create a book that serves as a reference. You don’t need to read all of this book, or all of any patterns book, to find it useful. You just need to read enough to have a sense of what the patterns are, what problems they solve, and how they solve them. You don’t need to know all the details but just enough so that if you run into one of the problems you can find the pattern in the book. Only then do you need to really understand the pattern in depth.
Once you need the pattern, you have to figure out how to apply it to your circumstances. A key thing about patterns is that you can never just apply the solution blindly, which is why pattern tools have been such miserable failures. I like to say that patterns are “half baked,” meaning that you always have to finish them off in the oven of your own project. Every time I use a pattern I tweak it a little here and a little there. You see the same solution many times over, but it’s never exactly the same.
Each pattern is relatively independent, but patterns aren’t isolated from each other. Often one pattern leads to another or one occurs only if another is around. Thus, you’ll usually only see Class Table Inheritance (285) if there’s a Domain Model (116) in your design. The boundaries between the patterns are naturally fuzzy, but I’ve tried to make each pattern as self-standing as I can. If someone says “Use a Unit of Work (184),” you can look it up and see how to apply it without having to read the entire book.
If you’re an experienced designer of enterprise applications, you’ll probably find that most of these patterns are familiar to you. I hope you won’t be too disappointed (I did try to warn you in the Preface). Patterns aren’t original ideas; they’re very much observations of what happens in the field. As a result, we pattern authors don’t say we “invented” a pattern but rather that we “discovered” one. Our role is to note the common solution, look for its core, and then write down the resulting pattern. For an experienced designer, the value of the pattern is not that it gives you a new idea; the value lies in helping you communicate your idea. If you and your colleagues all know what a Remote Facade (388) is, you can communicate a lot by saying, “This class is a Remote Facade.” It also allows you to say to someone newer, “Use a Data Transfer Object for this,” and they can come to this book to look it up. The result is that patterns create a vocabulary about design, which is why naming is such an important issue.
While most of these patterns are truly for enterprise applications, those in the base patterns chapter (Chapter 18) are more general and localized. I include them because I refer to them in discussions of the enterprise application patterns.
Every author has to choose his pattern form. Some base their forms on a classic patterns book such as [Alexander et al.], [Gang of Four], or [POSA]. Others make up their own. I’ve long wrestled with what makes the best form. On the one hand I don’t want something as small as the GOF form; on the other hand I need to have sections that support a reference book. So this is what I’ve used for this book.
The first item is the name of the pattern. Pattern names are crucial, because part of the purpose of patterns is to create a vocabulary that allows designers to communicate more effectively. Thus, if I tell you my Web server is built around a Front Controller (344) and a Transform View (361) and you know these patterns, you have a very clear idea of my web server’s architecture.
Next are two items that go together: the intent and the sketch. The intent sums up the pattern in a sentence or two; the sketch is a visual representation of the pattern, often but not always a UML diagram. The idea is to create a brief reminder of what the pattern is about so you can quickly recall it. If you already “have the pattern,” meaning that you know the solution even if you don’t know the name, then the intent and the sketch should be all you need to know what the pattern is.
The next section describes a motivating problem for the pattern. This may not be the only problem that the pattern solves, but it’s one that I think best motivates the pattern.
How It Works describes the solution. In here I put a discussion of implementation issues and variations that I’ve come across. The discussion is as independent as possible of any particular platform—where there are platform-specific sections I’ve indented them so you can see them and easily skip over them. Where useful I’ve put in UML diagrams to help explain them.
When to Use It describes when the pattern should be used. Here I talk about the trade-offs that make you select this solution compared to others. Many of the patterns in this book are alternatives; such Page Controller (333) and Front Controller (344). Few patterns are always the right choice, so whenever I find a pattern I always ask myself, “When would I not use this?” That question often leads me to alternative patterns.
The Further Reading section points you to other discussions of this pattern. This isn’t a comprehensive bibliography. I’ve limited my references to pieces that I think are important in helping you understand the pattern, so I’ve eliminated any discussion that I don’t think adds much to what I’ve written and of course I’ve eliminated discussions of patterns I haven’t read. I also haven’t mentioned items that I think are going to be hard to find, or unstable Web links that I fear may disappear by the time you read this book.
I like to add one or more examples. Each one is a simple example of the pattern in use, illustrated with some code in Java or C#. I chose those languages because they seem to be languages that the largest number of professional programmers can read. It’s absolutely essential to understand that the example is not the pattern. When you use the pattern, it won’t look exactly like this example so don’t treat it as some kind of glorified macro. I’ve deliberately kept the example as simple as possible so you can see the pattern in as clear a form as I can imagine. All sorts of issues are ignored that will become important when you use it, but these will be particular to your own environment. This is why you always have to tweak the pattern.
One of the consequences of this is that I’ve worked hard to keep each example as simple as I can, while still illustrating its core message. Thus, I’ve often chosen an example that’s simple and explicit, rather than one that demonstrates how a pattern works with the many wrinkles required in a production system. It’s a tricky balance between simple and simplistic, but it’s also true that too many realistic yet peripheral issues can make it harder to understand the key points of a pattern.
This is also why I’ve gone for simple independent examples instead of a connected running examples. Independent examples are easier to understand in isolation, but give less guidance on how you put them together. A connected example shows how things fit together, but it’s hard to understand any one pattern without understanding all the others involved in the example. While in theory it’s possible to produce examples that are connected yet understandable independently, doing so is very hard—or at least too hard for me—so I chose the independent route.
The code in the examples is written with a focus on making the ideas understandable. As a result several things fall aside—in particular, error handling, which I don’t pay much attention to since I haven’t developed any patterns in this area yet. They are there purely to illustrate the pattern. They are not intended to show how to model any particular business problem.
For these reasons the code isn’t downloadable from my Web site. Each code example in this book is surrounded with too much scaffolding to simplify the basic ideas so they’re worth anything in a production setting.
Not all the sections appear in all the patterns. If I couldn’t think of a good example or motivation text, I left it out.
As I indicated in the Preface, this collection of patterns is by no means a comprehensive guide to enterprise application development. My test for this book is not whether it’s complete but merely if it’s useful. The field is too big for one mind, let alone one book.
The patterns here are all ones that I’ve seen in the field, but I’m not going to claim I completely understand all of their ramifications and interrelationships. This book reflects my current understanding, and that understanding has developed as I’ve been writing the book. I expect it will continue to evolve long after this book has turned into paper. One certainty of software development is that it never stands still.
As you consider using the patterns, never forget that they’re a starting point, not a final destination. There’s no way that any author can see all the many variations that software projects have. I’ve written these patterns to help provide a beginning, so you can read about lessons that I, and the people I’ve observed, have learned from doing and struggling. You’ll have your own struggles on top of these. Always remember that every pattern is incomplete and that you have the responsibility, and the fun, of completing it in the context of your own system.