Book review : Patterns of Enterprise Application Architecture

I read “Patterns of Enterprise Application Architecture” by Martin Fowler. There are contributions from other authors Dave Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford as well for this book. This book was written in 2002. The book is organised into two major parts, first part deals with introduction into patterns, second part provides the in-depth details about the patterns introduced earlier.

The book starts with a precise effort to define what is an Enterprise Application. There are few examples of Application mentioned. These examples are classified as which ones are Enterprise Application and which ones are not. This section is followed by some explanation of terms used e.g response time, responsiveness, throughput, latency, horizontal scaling, vertical scaling etc ….

I would say this book is a classic in spite of the fact it was released in 2002. Most of the concepts are highly relevant and useful even today. In simple words what this book describes is

1. A collection of Enterprise applications pattern templates which are already well designed and used successfully in Production environments
2. Classification of patterns based on topics like Layering of software, Concurrency, Session management and Base Patterns
3. Explanation of the pattern with sequence diagrams, class hierarchy and schema diagrams
4. When to use a pattern and what are the pros and cons of using the pattern
5. Notes on how to implement the pattern and code examples in Java, C#

The complete set of patterns are documented in the web here at https://www.martinfowler.com/eaaCatalog

One of the initial set of questions that pops up when an Enterprise application is designed would be

What should be put where? How do I deal with such a big blob of code? Which component will own which responsibility?What kind of interactions should be there between various components?

Separation of concerns, orthogonality will help solve these kind of problems. Layering will aid Separation of concerns principle and ensure clarity in organising software. Software designed as layers will guarantee that changes done are minimal and done only in the right places. Badly written software will be cluttered and hard to understand. In such bad code, to make simple changes multiple unrelated files, functions will be touched leading to a worser state than ever before and this rot will be perpetual. Layering will attack this problem straight and bring huge discipline in organising responsibilities of different components. First concept dealt with in this book is layering and starts off with a reference to OSI layers as an example.

Layering is explained in terms of three principal layers: Domain Logic (Business Logic / Business rules), Data Source (Database, Communication systems) and Presentation (User Interface / UI)

Domain Logic patterns are explained in three variants Transaction Script, Domain Model and Table Module. Of all these three, transaction script is the easiest to understand that can be used for less complex domain logic. If you have more complex domain logic, you may need Domain Model pattern and this happens to be book author’s favourite pattern. Table module fits well if your implementation language is C# as per author, please consider the year the book was written as well as other languages might have caught up too.

Simplest idea that would help peek into these domain logic patterns would be seeing them as, Transaction script is procedure oriented, Domain model would be design of objects and their interactions oriented, Table module is database table, tabular data oriented. All these patterns are clearly explained with diagrams and sample code.

Service layer is explained as the layer with which clients interact and it serves as boundary between clients and interfaces exposed by services. This layer will be the access mechanism to domain logic implementation for the outside world. There is a nice diagram in page 133 of 2002 edition to refer to.

Data Source Patterns follow the layers section. Data source layer removes the headache of how actual data is accessed from a database. This layer provides the convenience of separating SQL, database intricacies from domain logic.Table Data Gateway, Row Data Gateway, Active Records, Data Mapper patterns are explained clearly with examples. A keen reader who understands all these patterns will quickly be able to correlate with off shelf libraries like hibernate ORM and discover the underlying patterns.

Object Relational patterns. These patterns make accessing data from database easier as if they were accessed like objects for read/write/update/delete operations. Numerous patterns are explained in this topic which includes Unit of Work, Identity Map, Lazy load, Identity Field, Foreign Key Mapping, Association Table Mapping, Dependent Mapping, Embedded Value, Serialized LOB, Single Table Inheritance, Class Table Inheritance, Concrete Table Inheritance, Inheritance Mappers, Metadata Mapping, Query Object, Repository.

It’s going to be a long read to mention all of these object relational patterns as to how they are explained in the book, I will make brief mention of some of them. Some patterns work in combination. To implement a pattern another set of pattern is required. But this is an interesting topic e.g unit of work pattern talks about marking data objects as dirty when they are updated and on a commit operation on the object, persists data directly in database. Lazy loading does just in time loading of data only when required instead of loading all related fields in one shot. This is a performance optimisation pattern. Single Table Inheritance, Class Table Inheritance, Concrete Table help deal with inheritance patterns. I have met these situations on how to deal with common fields across tables in database. Some of these patterns may be taken for granted as of today, as advanced ORMs like hibernate hide these patterns under the hood.

Web Presentation Patterns follow the data handling patterns. This is a set of patterns of how to render html based views on browser. Model-View-Controller(MVC), Page Controller, Front Controller, Template View, Transform View, Two Step View, Application Controller patterns are dealt in this section.

MVC is the most popular as most frameworks use this today and almost all programming languages have a couple of competing MVC frameworks. This is very simple to understand. In controllers there are two kinds of them explained viz.. page and front. Page controller handles input per page whereas Front controller is a global single common controller for an application. Two important ways of rendering i.e Template view and Transform view are explained. Template view is implemented by having some markers in the form of some variables injected at runtime and rendered finally as html. I am a big fan of this approach since I have seen the ease of doing them in Laravel, ReactJS of the style {author}, {username}. Transform view is mainly about rendering based on xml, xslt in a style sheeted way. In this approach xml is generated first and then a html view is generated from the xml based on style specifications.

Distribution Patterns come next in the order of topics arranged after presentation patterns. Remote Facade, Data Transfer Object are the patterns found in this section.

Remote Facade is a pattern which gets more coarse grained data from remote resource. This prevents multiple calls to fetch each and every fine grained data required. For e.g remote facade may fetch a books name, isbn, publisher’s information in one shot even though there was only a call to fetch isbn alone. This is some kind of eager loading which avoids multiple network calls and improves performance. Data transfer object is about packing more data in some kind of an umbrella object inside which lot of grouped data is transferred across responses and requests. This pattern aids in avoiding numerous calls by grouping more data together as coarse grained data holder object. A Data transfer object should be serialisable for sending over wire.

Offline Concurrency Patterns deal with how to handle concurrency and data consistency at the same time, deadlock avoidance etc... Optimistic Offline Lock, Pessimistic Offline Lock, Coarse Grained Lock, Implicit Lock patterns are explained in this section. This is a very important section where you may want to pay more attention.

Optimistic and Pessimistic locks are mentioned in the earlier part of the book where concurrency topic is introduced. In the same introductory section you will find ACID, four isolation levels (table 5.1) explained. Optimistic locks allow simultaneous modification by two or more writers and has some way to resolve conflicting data. Pessimistic locking allows only one writer to write and all other writers should wait till the first writer is done. In these locks optimism can be seen as locking that promotes concurrency for multiple writers, pessimism as reduced concurrency. Both these locks have their strengths, this is clearly explained in the book and they have direct impact on user experience. You can choose either one based on the specific use case. Coarse grained lock is fascinating where only one lock is obtained to secure a set of resources. With coarse grained lock you don’t have to lock individual resources and end up with a set of locks guarding their respective resources.

Concurrency related bugs are tougher to handle as they may not be reproducible in your test environment but will pop up in production, so get this right the first time and needs a thoughtful design.

Session State Patterns talk about how to store state across sessions. Simple example would be something like after logging in, a user browsed 3 to 4 products on a weekend and comes back again on the next weekend. Should he login again? How to show the last set of products he browsed? Short answer is to maintain states across sessions. Maintaining states across sessions is explained in the patterns Client Session State, Server Session State, Database Session State

Storing session data on the client side is done in client session state. URL parameters, cookies and hidden input fields are explained. Some advice on security aspects like encryption, randomising session id, hashing are given. Incase of server session state server stores the session state info in memory. Some references to Session bean, EJB are mentioned on how server session state could be implemented. Last pattern covered under this topic is the database session state which saves state in database. The difference between in memory and database session may be a little blurred with usage of Caching tools like Redis, where both in memory and persistence is possible at the same time.

Base Patterns topic covers patterns like Gateway, Mapper, Layer Supertype, Separated Interface, Registry, Value Object, Money, Special Case, Plugin, Service Stub, Record Set.

Base patterns can be used along with other Patterns. I found two favourites here Plugin and Registry. Plugin pattern helps in injecting dependencies which is very common in Spring world also known as auto wiring. Registry pattern suggests using thread local storage facilities, where you can avoid passing lot of parameters around to multiple objects and avoid using globals. If your programming language supports thread local storage then registry pattern is easy to use. Also checkout the Money pattern which brings out a deeper analysis on issues one may face.

Who should read this book?

1. Enterprise Application Architects — its a must read
2. Software engineers who want to dig which patterns are used in a particular tool e.g ORM, ReactJS
3. If your organisation is mulling over design decisions as to what to choose and what tradeoffs you will have to make. You are the person who is going to design a service
4. Software engineers who would like to understand existing patterns and avoid thinking / reinventing

Concluding remarks

1. This book will help you systematically explore areas of consideration when you design an enterprise application.
2. All topics are neatly organised with clear information on what is the pattern, when to use them and supplemented with code examples
3. This book is a patterns reference catalogue, you don’t have to memorise all of them. You can always take a plunge on specific patterns whenever you need them
4. Don’t be fooled by the age of the book, however I wish there were an updated version of this book
5. There are references to design patterns like Facade, Strategy, Memento etc … which would help you understand easily. You can google for Gang of four design patterns
6. Consider the latest developments which are available e.g Springs dependency injection, ORM implementations. Some of these tools you can use them without having to understand complete pattern
7. There are nuggets of wisdom found in the book here and there. E.g Author states he values continuous integration, test driven development and refactoring. If one pays attention, these extra advice would be helpful.
8. Reading this book cover to cover is time consuming but still worth the effort. Also some experienced people may already know these patterns prior e.g MVC, active records etc…
9. Numerous references / further reading items are mentioned in this book e.g Applying UML and Patterns by Craig Larman. This should help you explore further
10. You are going to end up with some amount of confusion like, how is pattern A different from pattern B? Solution to this is to read those patterns again, google. Then things will be obvious.