After reading several design pattern books including “Head first design pattern” and “Java and Pattern” I turned my focus to one new book named Patterns of Enterprise Application Architecture. From the comments of amazon it seems that it’s one pretty good book. Considering the limited memory now, writing down some key ideas from the book should be able to keep the reading more interesting.
The preface section defines the scope of this book which is architecture for enterprise application. The common patterns of enterprise applications include data persistence, concurrent access, huge data process, complex UI, and integration to other enterprise application.  Here the UI involves Web and traditional rich client application. Also the authors gives some points on the measurement for performance. Finally the form of pattern is given which contains name, intention, summary,  how it works, when to use it and further reading, also some examples maybe also presented for better understanding.
The first chapter talks about layering. This topic starts from the evolution from the Client/Server model to three principal layers. One problem of the traditional C/S model is that the domain logic is hard to organized. It’s a bad idea to mix the logic in client UI directly which may easily causes duplicated code and maintain issues. Alternative way is putting them to the server side which usually presented as database store procedure. Here the store procedure is limited and may causes difficulty to switch to different database.
These short comes naturally involves idea to separate the domain logic in the object oriented world. This results in the new three principle layers including Presentation, Domain and Data source. one interesting point raised by author to think about the Presentation and Data source layer is that “Presentation is an external interface for a service your system offers to someone else, whether it be a complex human or a simple remote program. Data source is the interface to things that are providing a service to you”. Also one principle here is “The domain and data source should never be dependent on the presentation” which means we should be able to easily change our presentation layer without requiring changes in domain logic layer.
The benefits of layering contains: Easy to understand separated layer, minimize dependencies between different layers, substitute layers with alternative implementations of the same basic services. One obvious drawback of layering is that performance as we need to pass data to different layers. But compare to the benefits usually the cost is worthwhile.
The chapter 2 discusses about the way to organize domain logic.  Transaction Scripts, Domain Model, and Table Module. They all have pros and cons. The recommended way is Domain Model which is good at complexity when the problems scope increase.