Fowler - Patterns of Enterprise Application Architecture

Martin Fowler
With contributions from David Rice,
Matthew Foemmel, Edward Hieatt,
Robert Mee, and Randy Stafford

Boston San Francisco New York Toronto Montreal
London Munich Paris Madrid
Capetown Sydney Tokyo Singapore Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, please contact:

U.S. Corporate and Government Sales
(800) 382-3419

For sales outside of the U.S., please contact:

International Sales
(317) 581-3793

Visit Addison-Wesley on the Web: informit.com/aw

Library of Congress Cataloging-in-Publication Data

Fowler, Martin, 1963
Patterns of enterprise application architecture / Martin Fowler.
p. cm.
Includes bibliographical references and index.
ISBN 0-321-12742-0 (alk. paper)
1. System design. 2. Computer architecture. 3. Application software
Development. 4. BusinessData processing. I. Title.
QA76.9.S88 F69 2003
005.1dc21
2002027743

Copyright 2003 by Pearson Education, Inc.

All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. To obtain permission to use material from this work, please submit a written request to Pearson Education, Inc., Permissions Department, One Lake Street, Upper Saddle River, New Jersey 07458, or you may fax your request to (201) 236-3290.

ISBN 0-321-12742-0
Text printed in the United States on recycled paper at RR Donnelley in Crawfordsville, Indiana.

Twentieth printing, March 2014

For Denys William Fowler, 19222000
in memoriam

Martin

In the spring of 1999 I flew to Chicago to consult on a project being done by ThoughtWorks, a small but rapidly growing application development company. The project was one of those ambitious enterprise application projects: a back-end leasing system. Essentially it deals with everything that happens to a lease after youve signed on the dotted line: sending out bills, handling someone upgrading one of the assets on the lease, chasing people who dont pay their bills on time, and figuring out what happens when someone returns the assets early. That doesnt sound too bad until you realize that leasing agreements are infinitely varied and horrendously complicated. The business logic rarely fits any logical pattern, because, after all, its written by business people to capture business, where odd small variations can make all the difference in winning a deal. Each of those little victories adds yet more complexity to the system.

Thats the kind of thing that gets me excited: how to take all that complexity and come up with a system of objects that can make the problem more tractable. Indeed, I believe that the primary benefit of objects is in making complex logic tractable. Developing a good ) for a complex business problem is difficult but wonderfully satisfying.

Yet thats not the end of the problem. Our domain model had to be persisted to a database, and, like many projects, we were using a relational database. We also had to connect this model to a user interface, provide support to allow remote applications to use our software, and integrate our software with third-party packages. All of this on a new technology called J2EE, which nobody in the world had any real experience in using.

Even though this technology was new, we did have the benefit of experience. Id been doing this kind of thing for ages with C++, Smalltalk, and CORBA. Many of the ThoughtWorkers had a lot of experience with Forte. We already had the key architectural ideas in our heads, and we just had to figure out how to apply them to J2EE. Looking back on it three years later, the design is not perfect but it has stood the test of time pretty damn well.

Thats the kind of situation this book was written for. Over the years Ive seen many enterprise application projects. These projects often contain similar design ideas that have proven effective in dealing with the inevitable complexity that enterprise applications possess. This book is a starting point to capture these design ideas as patterns.

The book is organized in two parts, with the first part a set of narrative chapters on a number of important topics in the design of enterprise applications. These chapters introduce various problems in the architecture of enterprise applications and their solutions. However, they dont go into much detail on these solutions. The details of the solutions are in the second part, organized as patterns. These patterns are a reference, and I dont expect you to read them cover to cover. My intention is that you read the narrative chapters in as your interest and needs drive you. Thus, the book is a short narrative book and a longer reference book combined into one.

This is a book on enterprise application design. Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data. Examples include reservation systems, financial systems, supply chain systems, and many others that run modern business. Enterprise applications have their own particular challenges and solutions, and they are different from embedded systems, control systems, telecoms, or desktop productivity software. Thus, if you work in these other fields, theres nothing really in this book for you (unless you want to get a feel for what enterprise applications are like.) For a general book on software architecture, Id recommend [].

There are many architectural issues in building enterprise applications. Im afraid this book cant be a comprehensive guide to them. In building software Im a great believer in iterative development. At the heart of iterative development is the notion that you should deliver software as soon as you have something useful to the user, even if its not complete. Although there are many differences between writing a book and writing software, this notion is one that I think the two share. That said, this book is an incomplete but (I trust) useful compendium of advice on enterprise application architecture. The primary topics I talk about are

Layering of enterprise applications

Structuring domain (business) logic

Structuring a Web user interface

Linking in-memory modules (particularly objects) to a relational database

Handling session state in stateless environments

Principles of distribution

The list of things I dont talk about is rather longer. I really fancied writing about organizing validation, incorporating messaging and asynchronous communication, security, error handling, clustering, application integration, architectural refactoring, structuring rich-client user interfaces, among other topics. However, because of space and time constraints and lack of cogitation, you wont find them in this book. I can only hope to see some patterns for this work in the near future. Perhaps Ill do a second volume someday and get into these topics, or maybe someone else will fill these and other gaps.