Bellow is a small (rather long) review of Patterns of Enterprise Application Architecture.

I will keep writing summaries of books that i read, its possible that i would be the only one reading these summaries, However they if others may use the information provided here in anyway it would make me happy. So be my guest.


Presentation - Domain Logic - Data source

Presentation The things you provide to people (or service) (UI or interface of a lib)
Domain Logic The domain logic a mix of nouns (classes) and verbs (methods)
Data Source The places that you take data from (Remote/Database/Etc...)

1. Domain Logic Layer Patterns

Domain logic types.

Transaction scrip Model:

  • Logic class + Gateway class
  • Simple scripts, such as StoredProcedures

Domain Model:

  • Class for each domain object
  • Objects decoupled from DB
  • Object holds data and methods

Table Module:

  • Each class represent a DB Table
  • Accepts RecordSets (Cursors) as input and does Logic on them.
  • Class does not hold a state, its just a collection of methods (static methods)

2. Data Source Layer Patterns

Dealing with persistence (DB or Remote)

Active Record

Used with Domain Model.

  • Handle Domain Logic + Persistency
  • Similar to Row Data Gateway + Domain Model
  • Handles all CRUD.
  • Find/List methods can be separated in a different class.

Data Mapper

Used with Domain Model.

  • A mapper layer that moves data between objects and db
  • Handles writing/reading a Domain model object to/from a persistent store
  • Handles all CRUD.
  • Domain Model and db tables are different in design.
  • If domain model needs to use Finder/List method, don't expose the whole Data Mapper, instead create a Find/List interface expose it to the Model, and Have the Data Mapper implement it.

Row Data Gateway

Used with Transaction Script Model.

  • Object that acts as a Gateway to a DB Table row,
  • Handles all CRUD.
  • Find/List methods can be separated in a different class.
  • One instance represent a Table Row.
  • Does not contain any domain logic.

Table Data Gateway

Used with Table Model.

  • Object that acts as a Gateway to a DB table.
  • Handles all CRUD.
  • Stateless.
  • Returns queries RecordSet, Hash map or Domain Models

3. Object Relational Behaviour Patterns

Unit of Work

Maintains a list of objects affected by a transaction, and handles their dirty/clean states and their commit operations.

  • Register an object as dirty.
  • When commit called, write all dirty in DB.
  • Manages relational integrity.

Identity Map Pattern

Ensures that each object is loaded in memory only once, maintains a Hash map of all loaded objects.

  • Caches the object loaded in a Map

Lazy Load Pattern

Object that does not contain all the data, but it knows how to get it.

Lazy Initialisation

When we access a field, we check if its null, if it is then we load it.

Virtual Proxy

The field contain a proxy object that has the same interface, when accessed it go fetches the correct object from the db.

Value holder

The field contains an object that holds the requested object, only when we call value() on the holder it goes to fetch the real object.


The field is the correct object partially loaded, contains only the ID when you try to access its fields, it loads the rest of the data from the db.

4. Object Relational Structural Patterns

Identity Field

Save a db field in the object to maintain object-db sync.
We add an ID field in the domain model, this field will be nil if its not loaded from the db, when its loaded from the db this field will have the correct row ID.

Foreign Key Mapping

Map association between objects to a foreign key reference between tables.

  • handles 1:1 and 1:many
  • Load the first object.
  • Then take the foreign ID and load it using its appropriate Mapper.

Association Table Mapping

Maps the association of Many:Many

ex: employee:skill

  • EmployeeMapper handles the employe table and the employe_skills table
  • SkillMapper it deals with loading a single skill

Dependent Mapping

One parent class perform mapping for a child class, child class is dependent on Parent class. (also maintain its live cycle)

  • The dependent class will have no db code and it will have no Data Mapper.
  • Only the owner knows about the dependent.

Embedded Value

Maps an object into several fields of another object's table.

  • Dependent object gets flatten when saved to db and gets written in the same owner object table.
  • All Value Objects should be saved as Embedded Values

Serialized LOB

Save a subgraph of the object as a serialized LOB.

  • When we save an object, a subgraph of this object gets serialized and saved as one LOB value.
  • The LOB cannot be queried.
  • The owner is responsible for serializing and de serializing the LOB.

Single Table Inheritance

Represent an inheritance hierarchy as a single table that has columns for all the fields + a type field.

  • Some fields will be empty.
  • When creating an object for a row, the type field will determine which object to instantiate.

Class Table Inheritance

Represent an inheritance hierarchy as one table for each class.

  • One of the main issues is how to link different tables together.

Concrete Table Inheritance

Represent an inheritance hierarchy as one table for each concrete class.

  • Duplicates super fields in the sub tables.

Inheritance Mappers

A structure to organise database mappers that handle inheritance hierarchies.

  • Create a mapper for each class and subclass, abstract and concrete.
  • Subclass will implement:
    • Subclasses will implement Find, Load, and Save
    • Load/Save method is defined in the Subclass, it loads the data in its fields and then it calls the super load to load the rest of the fields.
  • A Factory Class will exist to make decisions on the scale of the whole hierarchy.
    • Find Method, will find a concrete class and return it.

5. Object-Relational Metadata Mapping Patterns

How to map to a db?

Metadata Mapping

Holds details of object-relational mapping in metadata.

  • It could be implemented as a Generate Code (Build Script)
  • Or with Reflection.

Query Object

An object that represents a database query.

  • Refer to an query by class and params.
  • It can eliminate redundant SQL queries.
  • Turn SQL to an object.


Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

  • Mediate between Model And Data Mapper.
  • Repository has the same interface of a Simple Collection.
  • It shields the program from the persistence layer.

6. Web Presentation Patterns



  • Separate Model from View
  • Handle Model-View Communication
  • View and Controller could be mixed, but Controller and Model should be separated.

Page Controller.

An controller that handles a request for a specific page or action on a Web site.

  • Act as the entry point for the page.
  • Decodes the Request.
  • Creates the model.
  • Decide which View to use.

Front Controller.

A controller that handles all requests for a Web site.

  • Act as the entry point for the site.
  • Web handler, examines the URL, then it forwards it to a concrete command.
  • The Command will then decide the model and view.

Application Controller.

A centralised point for handling screen navigation and the flow of an application.

  • Acts as a state machine for the UI
  • Handle navigations in a Wizard style navigation.
  • Decides the domain logic.
  • Decides which view to use.

Template View

Renders information into HTML by embedding placeholders in an HTML page.

  • Minimise the code in the template view.

Transform View

A view that processes domain data element by element and transforms it into HTML.

  • Transforms Domain objects to HTML.
  • Easier to test from template view.

Two Step View.

Create a view on two steps, first step cares about the logical presentation and the second about the actual.

  • The first step has no HTML. it produce logical format.
  • Second stage converts the logical tags to actual HTML.
  • The second stage is common on the whole site.

7. Distribution Patterns

Remote Facade

Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network.

  • Coarse interface minimises the number of calls.
  • Remote facade should not have domain logic.
  • such as a Web Service.

Data Transfer Object.

An object that carries data between processes in order to reduce the number of method calls.

  • DTO carries more data from the requested.
  • DTO should be able to serialize itself.
  • An assembler/mapper transform a DTO from/to a Domain Object.

8. Session State Patterns

Client Session State

Stores the session on the client (cookies)

HTML example:
- Save session in URL, by appending data in each request. - Set data in hidden fields. - Cookies.

Server Session State

Stores the session on the server.

  • The server save the Session Data in mem/db using SessionID as the index.
  • Session ID will be sent back and forth with the client.

Database Session State

Similar to Server Session State, but always save the Session Data to a db.

9. Base Patterns

Gateway Pattern

An object that encapsulate access to an external resource or system (DB/Remote/etc...)
Its basically an Adapter pattern class

Mapper Pattern

An object that sets up the communication between two independent
independent systems.

Registry Pattern

A well-known object that other objects can use to find common objects and services.

  • Global object with static methods.

Null Object Pattern

If you do a lot of checking agains Null/Unknown, create a subclass of the object NullObject (SpecialObject, SpecialClass)

  • Employe, create NullEmployee

Plugin/Dependency Injection Pattern

A plugin is Factory Class, methods in this factory will read a text file that contains:

  1. The implementation of the object that using Reflection/Eval will be read and evaluated.
  2. Central config information that helps the factory decide what object to create.


  • Plugin = Factory Class + Config Text
  • Normally plugin has a method that takes a class name and return an object of that class

    obj = Plug.getPlugin(Person.Class);


Service Stub / Mock Object Pattern

Remove dependency on problematic services during testing.

  • Create Gateway on the problematic service
  • Have a Plugin (Factory Class) decide to create the real or stub service class