Patterns of EA Architecture

1. Patterns of Enterprise Application
Architecture
Ngo Nguyen Chinh
Ha Noi 2016

2. Contents
• Introduction
• The Narratives
• The Patterns

3. Part 1 - Introduction

4. Introduction
• Objectives of this Part
– Architecture
– Enterprise Applications
– Kinds of Enterprise Application
– Thinking About Performance

5. Architecture
• Usually, 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.
• There isn't just one way to state a system's architecture
• 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.
• Layer is the architecture pattern.
How you decompose an enterprise application into layers? How these layers work together?

6. Characteristics of Enterprise Applications
• There are usually the following characteristics:
– Have complex data
– Involve persistent data
– Have a lot of data
– Many people access data concurrently
– Have a lot of UI screens
– Need to integrate with other enterprise applications scattered around the enterprise.
– Not all enterprise applications are large
• Even though they can provide a lot of value to the enterprise.

7. Kinds of Enterprise Application
• Enterprise applications are all different and that different problems lead to different ways of doing
things.
• For example:
– B2C (business to customer) online retailer:
• Has very high volume of users
• Uses reasonably efficient in terms of resources
• Scalability (can increase the load by adding more hardware)
• Domain logic can be pretty straightforward
• A pretty generic Web presentation can be used with the widest possible range of
browsers
• Includes a database for holding orders
• Perhaps some communication with an inventory system

8. Kinds of Enterprise Application
• For example:
– A system that automates the processing of leasing agreements:
• Has many fewer users -- no more than a hundred or so at one time
• Has more complicated business logic
• Has more complexity in the UI
o A more conventional rich-client interface is needed
• Has a complex database schema (perhaps two hundred tables)
– A simple expense-tracking system for a small company:
• Has few users
• Has simple logic
• Can easily be made accessible across the company with an HTML presentation
• Has a few tables in a database
• Challenge is you have to build it very quickly
• Although such systems may be small, most enterprises have a lot of them so the
cumulative effect of an inappropriate architecture can be significant.

9. Thinking About Performance
• Many architectural decisions are about performance.
– It's better to get a system up and running, instrument it, and then use an optimization process
based on measurement.
– Some architectural decisions affect performance in a way that's difficult to fix with later
optimization.
– 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
– A significant change in configuration may invalidate any facts about performance

10. Thinking About Performance
• There are some terms:
– Response time: Amount of time it takes for the system to process a request from the outside
– Responsiveness: How quickly the system acknowledges a request as opposed to processing
it.
• 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.
– Latency: 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. Latency is also the reason why you should
minimize remote calls.

11. Thinking About Performance
• There are some terms:
– Throughput: How much stuff you can do in a given amount of time.
• A typical measure is transactions per second (tps)
• Although, the problem is that this depends on the complexity of your transaction.
– Load: How much stress a system is under
• It might be measured in how many users are currently connected to it.
– Load sensitivity: 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.
– 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.

12. Thinking About Performance
• There are some terms:
– The capacity of a system: An indication of maximum effective throughput or load.
– Scalability: 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
o Such as doubling how many servers you have to double your throughput.
• There are 2 kind of scalability:
o Vertical scalability (scaling up): means adding more power to a single server, such
as more memory.
o Horizontal scalability (scaling out): means adding more servers.

13. Thinking About Performance
• Design decisions don't affect all of these performance factors equally.
• For example:
– Say we have 2 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 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.
→ We can say that Swordfish has better horizontal scalability, even though Camel is
more efficient for less than five servers.

14. Thinking About Performance
• 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.
• 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.

15. Patterns
• The focus of the pattern is a particular solution, one that's both common and effective in dealing
with one or more recurring problems.
• So, when we study about patterns, how we should study? We just need to read enough to have a
sense of:
– what the patterns are?
– what problems they solve?
– how they solve problems?
• Of course, once you need the pattern, you have to figure out how to apply it to your
circumstances.

16. Part 2 - The Narratives

17. The Narratives
• Objectives of this Part
– Layering
– Organizing Domain Logic
– Mapping to Relational Databases
– Web Presentation
– Concurrency
– Session State
– Distribution Strategies
– Putting It All Together

18. Chapter 1: Layering

19. What is the layering?
• Layering is one of the most common techniques
• Use to break apart a complicated software system
− The principal subsystems in software arranged similar to some form of layer cake
− The higher layer uses various services defined by the lower layer, but the lower layer in
unware of the higher layer
• The hardest part of a layered architecture is deciding what layers to have and what the
responsibility of each layer should be.

20. Benefits
• Can understand a single layer as a whole without knowing much about the other layers
• Can substitute layers with alternative implementations of the same basic services
− An FTP service can run without change over ethernet, PPP, or whatever a cable company
uses.
• Minimize dependencies between layers.
− If the cable company changes its physical transmission system, providing they make IP work,
we don't have to alter our FTP service.
• Layers make good places for standardization.
− TCP and IP are standards because they define how their layers should operate.
• Reusable
− Once you have a layer built, you can use it for many higher-level services.
− Thus, TCP/IP is used by FTP, telnet, SSH, and HTTP.

21. Downsides
• Layers encapsulate some, but not all, things well. As a result you sometimes get cascading
changes.
– For example: In a layered enterprise application is adding a field that needs to display onthe
UI, must be in the database, and thus must be added to every layer in between.
• Extra layers can harm performance.
− At every layer things typically need to be transformed from one representation to another.
However, the encapsulation of an underlying function often gives you efficiency gains that
more than compensate
− A layer that controls transactions can be optimized and will then make everything faster.

22. Evolution
• The early days of batch system:
– No layers
• In the 90's with the rise of client–server systems:
– These were 2-layer systems:
• The client held the UI and other application code
• The server was usually a relational database
• Downsides:
o Embedding logic in screens made is easy to duplicate code
o As the domain logic got more complex, this code became very difficult to work with
o An alternative was to put the domain logic in the database as stored procedures.
However, stored procedures gave limited structuring mechanisms, which again led
to awkward code
• At time the object-oriented world was rising:
− Move to 3-layer system:
• A presentation layer for UI
• A domain layer for domain logic
• A data source
− This way you could move all of that intricate domain logic out of the UI and put it into a layer
where you could structure it properly with objects
→ This is an answer to the problem of domain logic

23. The 3 Principal Layers
What is the layers?
• Presentation logic: Is about how to handle the interaction between the user and the software.
− The primary responsibilities of the presentation layer are:
• To display information to the user
• And to interpret commands from the user into actions upon the domain and data
source.
• Domain logic (business logic): It involves calculations based on inputs and stored data, validation of
any data that comes in from the presentation, and figuring out exactly what data source logic to
dispatch, depending on commands received from the presentation.
• Data source logic: Is about communicating with other systems that carry out tasks on behalf of the
application.
− For most enterprise applications the biggest piece of data source logic is a database that is
primarily responsible for storing persistent data.

24. The 3 Principal Layers
• Sometimes the layers are arranged so that the domain layer completely hides the data source from
the presentation.
• More often, however, the presentation accesses the data store directly. While this is less pure, it
tends to work better in practice.
– The presentation may interpret a command from the user, use the data source to pull the
relevant data out of the database
– And then let the domain logic manipulate that data before presenting it on the glass.

25. The 3 Principal Layers
• Separation: How you separate them depends on how complex the application is.
– A simple script to pull data from a database and display it in a Web page may all be one
procedure. It would be better to separate the three layers. In this simple case we might do it
only by placing the behavior of each layer in separate subroutines
– As the system gets more complex, we would break the three layers into separate classes
– As complexity increased we would divide the classes into separate packages
− Choose the most appropriate form of separation for your problem but make sure you do some
kind of separation -- at least at the subroutine level.

26. The 3 Principal Layers
• A rule about dependencies:
– The domain and data source should never be dependent on the presentation.
• That is, there should be no subroutine call from the domain or data source code into the
presentation code.
• This rule makes it easier to substitute different presentations on the same foundation and
makes it easier to modify the presentation without serious ramifications deeper down.
– The relationship between the domain and the data source is more complex and depends upon
the architectural patterns used for the data source.

27. Choosing Where to Run Layers
• Data source: Almost always runs only on servers
– The exception is where you might duplicate server functionality onto a suitably powerful client,
usually when you want disconnected operation.
– In this case changes to the data source on the disconnected client need to be synchronized
with the server
• Domain logic:
− Can run business logic all on the server or all on the client, or can split it.
– Again, all on the server is the best choice for ease of maintenance.
– The demand to move it to the client is for either responsiveness or disconnected use.
• Presentation: The decision of where to run it depends mostly on what kind of UI you want.
– Running a rich client pretty much means running the presentation on the client
– Running a Web interface pretty much means running on the server
– The primary reason that people want a rich-client presentation is that some tasks are
complicated for users to do and, to have a usable application, they'll need more than what a
Web GUI can give
• Should try to keep all the code in a single process, either on one node or copied on several nodes
in a cluster.
− Don't try to separate the layers into discrete processes unless you absolutely have to. Doing
that will both degrade performance and add complexity

28. Chapter 2: Organizing Domain Logic

29. Domain Layer Patterns
• There are 3 primary patterns
– Transaction Script: Organizes business logic by procedures where each procedure handles
single request from the presentation
– Domain Model: An object model of the domain that incorporates both data and behavior
– Table Module: One class that provides domain logic to table or view in database

30. Comparing
Transaction Script
Domain Model Table Module

31. Making a Choice
• These patterns depend on
– Complexity of the domain logic
– How the domain maps to the database

32. Service Layer
• A common approach in handling domain logic is to split the domain layer in two
− A Service Layer is placed over an underlying Domain Model or Table Module
• Usually you only get this with a Domain Model or Table Module
• A domain layer that uses only Transaction Script isn't complex enough to warrant a
separate layer
− The presentation logic interacts with the domain purely through the Service Layer, which acts
as an API for the application.

33. Chapter 3: Mapping to Relational Databases

34. Mapping to Relational Databases
• The role of the data source layer is to communicate with the various pieces of infrastructure that an
application needs to do its job.
• A dominant part of this problem is talking to a database, which, for the majority of systems built
today, means a relational database.

35. Good Design
• Separate database code from other code
– Provide database classes to access the database
– All SQL code in the same place
– Factories for each database
– Use of Connection Pools
• Error handling
– SQLException is isolated in the Data Source Layer
– Wrap in domain specific exceptionsp use of runtime exception

36. Architectural Patterns
• It's better to separate SQL access from the domain logic and place it in separate classes
− A good way of organizing these classes is to base them on the table structure of the database
These classes then form a Gateway to the table
− The rest of the application needs to know nothing about SQL, and all the SQL that accesses
the database is easy to find
− There are 2 main ways to use a Gateway:
• Table Data Gateway
• Row Data Gateway
• In simple applications, the Domain Model is an uncomplicated structure. It corresponds pretty
closely to the database structure, with one domain class per database table.
− Such domain objects often have only moderately complex business logic
− Each domain object be responsible for loading and saving from the database, which is Active
Record
• Another way to think of the Active Record is that you start with a Row Data Gateway and
then add domain logic to the class
• A better way is to isolate the Domain Model from the database completely, by making an indirection
layer entirely responsible for the mapping between domain objects and database tables.
− This Data Mapper handles all of the loading and storing between the database and the
Domain Model and allows both to vary independently.

37. The Behavioral Problem
• How to get various object to load and save themselves to the database
– With objects in memory, how can keep track of modified objects?
– What if we have 2 of the same object in memory and both are changed?
– How can we maintain consistency and data integrity?
– What if you need object that is already in memory?

38. The Behavioral Problem
• Keeping track of changed objects
– Simple way is to have an object that keeps track of other objects
• Unit of Work
– The idea is this
• When object is loaded it is registered as "clean" in the Unit of Work
• If modified, it is marked "dirty"
• When writing all objects back, just write the dirty ones

39. The Behavioral Problem
• Keeping track of loaded objects
– What if you need an object from the database – Is it already loaded? And changed?
• Identity Map
– The idea is this
• Keep all objects in a map and check get them from the map
• If they are not in the map, load them from the database

40. The Behavioral Problem
• Loading objects
– For rich data models, what about loading object hierarchies?
• Do we need to load all linked objects?
• Lazy Load
• The idea is this
– We load part of the objects but maintain a placeholder that we use when the rest of the object
is needed

41. Structural Mapping Patterns
• When people talk about O/R mapping, mostly what they mean is these kinds of structural mapping
patterns
• Structural mapping patterns are used when mapping between in-memory objects and database
tables.
− These patterns aren't usually relevant for Table Data Gateway
− May use a few of them for Row Data Gateway or Active Record
− Probably need to use all of them for Data Mapper.
• Below is patterns for structural mapping:
– Identity Field
– Foreign Key Mapping
– Association Table Mapping
– Dependent Mapping
– Embbeded Value
– Seriablized LOB
– Single Table Inheritance
– Class Table Inheritance
– Concrete Table Inheritance
– Inheritance Mappers

42. Using Metadata
"Metadata is structured information that describes, explains, locates, or otherwise makes it
easier to retrieve, use, or manage an information resource. Metadata is often called data about
data or information about information“
National Information Standards Organization
• There are some patterns for O/R Metadata Mapping
− Metadata Mapping:
• Based on boiling down the mapping into a metadata file that details how columns in the
database map to fields in objects
− Query Object:
• Allows to build queries in terms of in-memory objects and data in such a way that
developers don't need to know either SQL or the details of the relational schema.
− Repository:
• Largely hides the database from view
• Any queries to the database can be made as Query Objects against a Repository
• And developers can't tell whether the objects were retrieved from memory or from the
database.
• Repository works well with rich Domain Model systems.

43. Chapter 4: Web Presentation

44. View Patterns
• There are 3 patterns to think about:
– Transform View
– Template View
– Two Step View

45. Input Controller Patterns
• There are 2 patterns for the input controller:
– Page Controller
– Front Controller

46. Chapter 5: Concurrency

47. Concurrency
• Enterprise system must support many simultaneous users
– Need to guaranty correctness of data
• Concurrency
– When computations overlap in time, and which may permit the sharing of common resource
between those overlapped computations
– When 2 users are updating the same data, race conditions can occur causing corrupt data

48. Concurrency Problems
• Martin opens file to work with
• David opens the same file, changes and finishes before Martin and saves the file
• Martin than saves his changes and David's changes are lost
Lost update

49. Concurrency Problems
• Martin needs to know how many files are in the concurrency package
• The package contains 2 sub-packages
• Martin counts the number in first package, then becomes busy
• In the mean time David adds new files to both packages
• The Martin continues and counts the files in the second package
Inconsistent read

50. Concurrency Problems
• Both problems cause a failure of correctness
 Result when 2 people are working on the same data at the same time
• To avoid these problems and provide correctness we must lock access to the data
– Only one person can work on the data at the same time
– Provides correctness
– Reduces concurrency
• Liveness suffers
– How much concurrent activity can go on

51. Execution Contexts
• Processing occurs in some context
– Two important contexts: request and session
• Request
– Single call from outside, system sends response
• Session
– Long-running interaction between client and server
– Multiple requests that must be linked together
– For example: user logs in, places items in a shopping cart, buys, logs out

52. Isolation and Immutability
• Isolation
– Partition the data so that any piece of it can only be accessed by one active agent (program or
thread)
– Only one thread can enter critical section or isolated zone at each
• Immutability
– Concurrency problems occurs for data that can be modified
– By recognizing immutable data we can relax concurrency concerns and share it widely

53. Optimistic and Pessimistic Concurrency Control
• Control of mutable data that can't isolate
• Pessimistic locking
– Martin opens the file
– When David wants to open the file, he'll get denial, saying it is already in use
– Conflicts avoidance
• Optimistic locking
– Martin and David both edit the same file
– David finishes first and saves
– Then Martin saves, he'll get an error since David has updated the file
– Conflict detection

54. Optimistic and Pessimistic Concurrency Control
• Problem with pessimistic locking
− Avoids concurrency and reduces efficiency
• Optimistic locking provide more efficiency
− Locks are only used on commit
– The problem is what happens on conflicts
• Which one to use?
– Based on frequency and severity of conflicts
– If conflicts are sufficiently rare or if the consequence is not great, optimistic locking works
better
– If conflicts are frequent and painful, pessimistic locks are better

55. Preventing Inconsistent Reads
• Inconsistent Reads
– Martin edits the Customer class and adds some calls to the Order class. Meanwhile David
edits the Order class and changes the interface. David compiles and checks in. Martin
compiles and checks in. Now the shared code is broken
• How to avoid this?
– Pessimistic Lock
• Avoids the problem
– Optimistic Lock
• Detects the problem

56. Preventing Inconsistent Reads
• Pessimistic Lock
 To read data you need a read lock and to write data you need to have write lock
 Many can have read lock, but if anymore has read lock, nobody can get write lock
 If anyone has write lock, nobody can get read lock
 Can lead to Deadlock
• Optimistic Lock
– Use timestamps or sequence number for version marker
– If someone tries to commit broken code it is detected and needs manual fix

57. Deadlock
• When 2 or more are waiting for each other
– David is using the Order file and is waiting for Customer file, but Martin has the Customer file
and is waiting for the Order file
– This can happen in the pessimistic approach
• Solutions
– Detect the deadlock and find a victim
– Release resources from the victim so other can progress
– Use timeouts

58. Transactions
• Transaction is a bounded sequence of work
– Both start and finish is well defined
– Transaction must complete on an all-or-nothing basis
• All resources are in consistent state before and after the transaction
• For example: Database transaction
– Withdraw data from account
– Buy the product
– Update stock information
• Transactions must have ACID properties

59. ACID properties
• Atomicity
– All steps are completed successfully – or rolled back
• Consistency
– Data is consistent at the start and the end of the transaction
• Isolation
– Transaction is not visible to any other until that transaction commits successfully
• Durability
– Any results of a committed transaction must be made permanent

60. Transactional Resources
• Anything that is transactional
– Use transaction to control concurrency
– Databases, printers, message queues
• Transaction must be as short as possible
– Provides greatest throughput
– Should not span multiple requests
– Long transactions span multiple request

61. Transactional Isolations and Liveness
• Transactions lock tables (or resources)
– Need to provide isolation to guarantee correctness
– Liveness suffers
– We need to control isolation
• Serializable Transactions
– Full isolation
– Transactions are executed serially, one after the other
– Benefits: Guatantees correctness
– Drawbacks: Can seriously damage liveness and performance

62. Isolation Level
• Problems can be controlled by setting the isolation level
– We don't want to lock table since it reduces performance
– Solution is to use as low isolution as possible while keeping correctness

63. Phantoms
• Description
– Transaction A read rows. Transaction B adds (INSERT) a new row. A reads rows again, but
now new row has been added, "phantom" row
– Repeatable Read isolation level

64. Unrepeatable Read
• Description
– Transaction A reads value. Transaction B updates the value. A repeats the read but now the
value is different
– Read Committed isolation level

65. Dirty Read
• Description
– Transaction A reads and updates value. Transaction B reads the value. Then A rollbacks and
resets value. B updates value
– Read uncommitted isolation level

66. Transactions
• Transaction is a bounded sequence of work
– Both start and finish is well defined
– Transaction must complete on an all-or-nothing basis
• All resources are in consistent state before and after the transaction
• For example: Database transaction
– Withdraw data from account
– Buy the product
– Update stock information
• Transactions must have ACID properties

67. Offline Concurrency
• Need ACID properties for Business Transactions
– Problem is with locking
– Application won’t be scalable because long transactions will turn the database into a major
bottleneck
• Solution
– Business Transaction are broken into short system transactions
– System must provide ACID properties between system calls

68. Chapter 6: Session State

69. Stateful Servers
• Stateful server must keep the state between requests.
• Problem with stateful servers
– Need more resources, limit scalability
– They take resources and cause server affinity.
– For example:
• 100 users make request every 10s, each request takes 1s
• One stateful object per user
• Object are Idle 90% of the time

70. Stateless Server
• Stateless servers scale much better
• Use fewer resources
• Each request is separate

71. Session State
• State that is relevant to a session
– State used in business transactions and belong to a specific client
– Data structure belonging to a client
– May not be consistent until they are persisted
• Session is distinct from record data
– Record data is a long-term persistent data in a database
– Session state needs to be committed to become record data.

72. Ways to Store Session State
• We have 3 player
– The Client using a web browser
– The Server running the web application and domain
– The Database storing all the data
• There are 3 basic choices:
– Client Session State
– Server Session State
– Database Session State

73. Chapter 7: Distribution Strategies

74. Distributed Architecture
• Distributed processing by placing objects different nodes

75. Distributed Architecture
• Benefits
– Load is distributed between different nodes giving overall better performance
– It is easy to add new nodes
– Middleware products make calls between nodes transparent
First Law of Distributed Object Design: Don't Distribute your objects!

76. Remote and Local Interfaces
• Local calls
– Calls between components on the same node are local
• Remote calls
– Calls between components on different machines are remote
• OOP
– Promotes fine-grained objects

77. Remote and Local Interfaces
• Local call within a process is very, very fast
• Remote call between 2 processes is order-of-magnitude slower
– Marshalling and un-marshalling of objects
– Data transfer over the network
• With fine-grained OO design, remote components can kill performance
• For example
– Address object has get and set method for each member, city, street...
– Will result in many remote calls

78. Remote and Local Interfaces
• With distributed architectures, interfaces must be course-grained
– Minimizing remote function calls
• For example
– Instead of having getters and setters for each field, bulk assessors are used

79. Distributed Architecture
• Better distribution model
 Load Balancing or Clustering the application involves putting several copies of the same
application on different nodes

80. Where You Have to Distribute
• As architect, try to eliminate as many remote call as possible
 If this cannot be archived choose carefully where the distribution boundaries lay
• Distribution Boundaries
 Client/Server
 Server/Database
 Web Server/Application Server
 Separation due to vendor differences
 There might be some genuine reason

81. Optimizing Remote Calls
• We know remote calls are expensive
• How can we minimize the cost of remote
• The overhead is
 Marshaling or serializing data
 Networrk transfer
• Put as much data into the call
 Course grained call
• Remote Facade

82. Part 3 - The Patterns

83. Chapter 9: Domain Logic Patterns

84. Transaction Script
• What Is It: Organizes business logic by procedures where each procedure handles a single
request from the presentation
• Most business applications can be thought of as a series of transactions
• A Transaction Script orginises all this logic primarily as a single procedure

85. Transaction Script
• When to Use It:
– Works well if model is simple
• Small amount of logic
• No state needed
• Moving data between presentation and database
– Problems
• Code duplication between transactions
• Common code tends to be duplicated
• Since no state is used, and each transaction is separate from any other, there might be
too many calls to database layer

86. Transaction Script
• Revenue recognitions example:
− One script handles all the logic
− Uses a data gateway to access data

87. Domain Model
• What Is It: An object model of the domain that incorporates both behavior and data

88. Domain Model
• What Is It:
– An OO Domain Model will often look similar to a database model, yet it will still have a lot of
differences:
• A Domain Model mixes data and process
• It has multivalued attributes
• It has a complex web of associations,
• And a Domain Model uses inheritance
– There are 2 styles of Domain Model in the field:
• Simple Domain Model
• Rich Domain Model
• How It Works:
– Object that represent data and business rules (behavior)

89. Domain Model
• Simple Domain Model
– Similar to the database design with mostly one domain object for each database table
– Simple Model can be Active Record
• Rich Domain Model
– Can look different from the database design, with inheritance, strategies, other patterns, and
complex webs of small interconnected objects
– Better for more complex logic, but is harder to map to the databse
– A rich Domain Model requires Data Maper

90. Domain Model
• When to Use It:
– More complex business domains need to build a Domain Model
• A Domain Model will give you many more options in structuring the code, increasing
readability and decreasing duplication
– If using Domain Model, a good choice for database interaction is Data Mapper
• This will help keep Domain Model independent from the database and is the best
approach to handle cases where the Domain Model and database schema diverge
– When you use Domain Model you may want to consider Service Layer to give your Domain
Model a more distinct API.

91. Domain Model
• Revenue recognitions example
– Multiple classes each with different responsibility
– Each class has data and logic to calculate

92. Table Module
• What Is It: A single instance that handles the business logic for all rows in a database table or
view.
– Organizes domain logic with one class per table in the database
• A single instance of a class contains the various procedures that will act on the data

93. Table Module
• How It Works:
– One class that provides domain logic to table or view in database
– The primary distinction with Domain Model is that, if you have many orders:
• A Domain Model will have one order object per order
• While a Table Module will have one object to handle all orders.

94. Table Module
• When to Use It:
– Table Module is very much based on table-oriented data, it makes sense when you're
accessing tabular data using Record Set (.NET)
• Table Module works better than a combination of Domain Model and Active Record
when other parts of the application are based on a common table-oriented data structure.
• Don't see Table Module very much in the Java environment,
o Although that may change as row sets become more widely used.
– Table Module doesn't give you the full power of objects in organizing complex logic.
• You can't have direct instance-to-instance relationships, and polymorphism doesn't work
well
• So, for handling complicated domain logic, a Domain Model is a better choice.

95. Service Layer
• What Is It: Defines an application's boundary with a layer of services that establishes a set of
available operations and coordinates the application's response in each operation.
– Enterprise applications typically require different kinds of interfaces: data loaders, user
interfaces, integration gateways, and others. These interfaces often need common
interactions with the application to access and manipulate its data and invoke its business
logic.
– A Service Layer encapsulates the application's business logic

96. Service Layer
• How It Works:
– Service Layer is a pattern for organizing Business Logic
– Kinds of Business Logic:
• Can divide Business Logic into 2 kinds:
o Domain logic: Having to do purely with the problem domain
 For example: Strategies for calculating revenue recognition on a contract
o Application logic: Having to do with application responsibilities
 For example: Notifying contract administrators, and integrated applications
 Application Logic is sometimes referred to as Workflow Logic
• But putting Application Logic into pure domain object classes has a couple of undesirable
consequences.
o Domain object classes are less reusable across applications
o Mixing both kinds of logic in the same classes makes it harder to reimplement the
application logic in
→ For these reasons Service Layer factors each kind of business logic into a separate layer

97. Service Layer
• How It Works:
– There are 2 basic approaches to implement Service Layer:
• Domain Façade
• Operation Script
– Domain Façade
• A Service Layer is implemented as a set of thin facades over a Domain Model
• The classes implementing the facades don't implement any Business Logic
• Rather, the Domain Model implements all of the business Logic.
− Operation Script
• A Service Layer is implemention of Application Logic
• Use the Domain Model for Domain Logic
• The operations available to clients of a Service Layer are implemented as scripts
• A Service Layer is comprised of these application service classes, which should extend
a Layer Supertype, abstracting their responsibilities and common behaviors.

98. Service Layer
• How It Works:
– The interface of a Service Layer class declares a set of application operations available to
interfacing client layers
– To Remote or Not to Remote:
• Service Layer classes are well suited to remote invocation
o However, remote invocation comes at the cost of dealing with object distribution
o The better to start with a locally invocable Service Layer whose method signatures
deal in domain objects
o Add remotability when need it (if ever) by putting Remote Facades on Service
Layer or having Service Layer objects implement remote interfaces.

99. Service Layer
• How It Works:
– Identifying Services and Operations:
• Identifying the operations are determined by the needs of Service Layer clients, the most
significant (and first) of which is typically a User Interface
• There's almost always a one-to-one correspondence between CRUD use cases and
Service Layer operations.
• Validation aside, the creation, update, or deletion of a domain object in an application
increasingly requires notification of other people and other integrated applications. These
responses must be coordinated, and transacted atomically, by Service Layer operations.
• To identify Service Layer abstractions to group related operations
o An applications can have several "subsystems”. In this case, it's better to have one
abstraction per subsystem, named after the subsystem.
o Abstractions reflecting major partitions in a domain model, if these are different
from the subsystem partitions,
(e.g: ContractsService, ProductsService)
o Abstractions named after thematic application behaviors
(e.g: RecognitionService)

100. Service Layer
• When to Use It:
– In an application with more than one kind of client of its business logic
– And complex responses in its use cases involving multiple transactional resources

101. Chapter 10: Data Source Architectural Patterns

102. Table Data Gateway
• What Is It: An object that acts as a Gateway to a database table. One instance handles all the
rows in the table
− Also called Data Access Objects – DAO

103. Table Data Gateway
• How It Works:
− Simple interface to a table with several find() methods and methods for maintaining data
− CRUD methods
− Acts as a gateway to a table
− One gateway for each table
− Finders return collection of DTOs or Record Set

104. Table Data Gateway
• When to Use It:
– Works particularly well with Table Module, where it produces a record set data structure for the
Table Module to work on
– Table Data Gateway is very suitable for Transaction Scripts.
– It often makes sense to have the Data Mappers talk to the database via Table Data Gateways.
– One of the benefits of using a Table Data Gateway to encapsulate database access is that the
same interface can work both for using SQL to manipulate the database and for using stored
procedures.
• Indeed, stored procedures themselves are often organized as Table Data Gateways.That
way the insert and update stored procedures encapsulate the actual table structure
– Useful for web application where Domain Model is used

105. Row Data Gateway
• What Is It: An object that acts as a Gateway to a single record in a data source. There is one
instance per row.

106. Row Data Gateway
• How It Works:
− Object that is exactly one single record
− Each table column is a field in the object
− Do not have logic
− Finder object
− Can be generated

107. Row Data Gateway
• When to Use It:
– The choice of Row Data Gateway often takes 2 steps: first whether to use a gateway at all
and second whether to use Row Data Gateway or Table Data Gateway
– We should use Row Data Gateway most often when we are using a Transaction Script.
• In this case it nicely factors out the database access code and allows it to be reused
easily by different Transaction Scripts
– We should not use a Row Data Gateway when we are using a Domain Model
– Row Data Gateway may be used very nicely with Data Mapper

108. Active Record
• What Is It: An object that wraps a row in a database table or view, encapsulates the database
access, and adds domain logic on that data.
– An object carries both data and behavior. Much of this data is persistent and needs to be
stored in a database.
– Active Record uses the most obvious approach, putting data access logic in the domain
object.
• This way all people know how to read and write their data to and from the database.

109. Active Record
• How It Works:
– The essence of an Active Record is a Domain Model in which the classes match very closely
the record structure of an underlying database.
• Each Active Record is responsible for saving and loading to the database
• And it is also responsible for any domain logic that acts on the data (Contain domain
logic)
– The data structure of the Active Record should exactly match that of the database: one field in
the class for each column in the table.

110. Active Record
• When to Use It:
– Active Record is a good choice for domain logic that isn't too complex
– In an initial design for a Domain Model the main choice is between Active Record and Data
Mapper.
• Active Record has the primary advantage of simplicity
o It's easy to build Active Records
o And they are easy to understand.
o Their primary problem is that they work well only if the Active Record objects
correspond directly to the database tables: an isomorphic schema.
• If business logic is complex, should use Data Mapper instead
o In this case, you'll soon want to use your object's direct relationships, collections,
inheritance, and so forth. These don't map easily onto Active Record.
– Another argument against Active Record is the fact that it couples the object design to the
database design.
→ This makes it more difficult to refactor either design as a project goes forward.
– Active Record is a good pattern to consider if you're using Transaction Script
• When beginning to feel the pain of code duplication and the difficulty in updating scripts
and tables that Transaction Script often brings

111. Data Mapper
• What Is It: A layer of Mappers that moves data between objects and a database while keeping
them independent of each other and the mapper itself.
– Separates the in-memory objects from the database. Its responsibility is to transfer data
between the two and also to isolate them from each other.
• With Data Mapper the in-memory objects needn't know even that there's a database
present; they need no SQL interface code, and certainly no knowledge of the database
schema
• Since it's a form of Mapper, Data Mapper itself is even unknown to the domain layer.

112. Data Mapper
• How It Works:
– Retrieve data: To load a person from the database, a client would call a find method on the
mapper. The mapper uses an Identity Map to see if the person is already loaded; if not, it
loads it.

113. Data Mapper
• How It Works:
– Update data: A client asks the mapper to save a domain object. The mapper pulls the data out
of the domain object and shuttles it to the database.

114. Data Mapper
• How It Works:
– For insert and updates
• The mapper must know what objects have changed, which new ones have been
created, and which ones have been destroyed.
• The Unit of Work pattern is a good way to organize this.
– An application can have one Data Mapper or several.
• If you're hardcoding your mappers, it's best to use one for each domain class or root of a
domain hierarchy
• If you're using Metadata Mapping, you can get away with a single mapper class.

115. Data Mapper
• When to Use It:
– Using Data Mapper is when you want the database schema and the object model to evolve
independently.
– Data Mappers are useful with Domain Model.
• Data Mapper's primary benefit is that when working on the Domain model, can ignore the
database (both in design and in the build and testing process)
• Can understand and work with the domain objects without having to understand how
they're stored in the database.
• Can modify the Domain Model or the database without having to alter either
– For simple Domain Model, an Active Record could be used, but as it becomes more
complicated some mapping is needed
– O/R mapping solutions can provide the mappers. E.g: Hibernate
– For most cases you should buy a database-mapping layer rather than building one yourself.

116. Chapter 11: Object Relation Behavioral Patterns

117. Unit of Work
• What Is It: Maintains a list of objects affected by a business transaction and coordinates the writing
out of changes and the resolution of concurrency problems.
– Keeps track of objects that are moved in and out of the database
• What has changed?

118. Unit of Work
• How It Works:
– Unit of Work is an object that tracks all changes to the database
– As soon as something affects the database, tell the Unit of Work
– The Unit of Work must know the state of objects
• Upon committing the Unit of Work decides what to do
• Application programmers don't have know what to write to the database
• Two methods
– Caller registration
– Object registration

119. Unit of Work
• Caller Registration
– User of the object has to remember to register the object with the Unit of Work for changes

120. Unit of Work
• Object Registration
– The object must register itself with the Unit of Work

121. Unit of Work
• When to Use It:
– When you have in-memory objects you need to synchronize with the database
– When you have many updates to objects and you want to avoid unneeded calls to the
database to save the object
• Benefits:
– Keeps the state of object in one place

122. Identify Map
• What Is It: Ensures that each object gets loaded only once by keeping every loaded object in a
map. Looks up objects using the map when referring to them
– Keeps a record of all the objects that have been read

123. Identify Map
• How It Works
– Contains a map of all loaded objects
– Provides method to get the objects
• Choice of Key
– Usually the primary key
• Explicit or Generic
– Explicit Identity Maps have method of the type of the object
• Person findPerson(1)
– Generic Identity Maps have generic objects and keys
• Object find("person", 1)

124. Identify Map
• How Many
– One map per class or per session
– Session maps works for database-unique keys
– For multiple maps, maintain one per class or per table
• Where to put them
– Identity maps need to be somewhere
– Can be part of Unit of Work
– Can be in a Registry
• Identity Maps can be used as cache
– Works well if objects are read-only

125. Identify Map
• When to Use It
– When you need to load objects to memory and you don't want them duplicated
– Main benefit of Identity Map is avoiding problems when object is updated in-memory
– For immutable object, such as Value Object, Identity Map is not needed – object may be
duplicated
• Performance
– When you need caching of objects for performance

126. Lazy Load
• What Is It: An object that doesn't contain all of the data you need but knows how to get it
– Load only the data that is needed
• Load the rest when it is needed

127. Lazy Load
• How It Works
– Object can contain other objects and associations
– Loading all the data might be too much
– Lazy Load delays loading until the objects are needed
• 4 Ways to implement Lazy Load
– Lazy Initialization
– Virtual Proxy
– Value Holder
– A ghost

128. Lazy Load
• Lazy Initialization
– Uses a special marker value (usually null) to indicate a field isn't loaded
– Every access to the field checks the field for the marker value and if unloaded, loads it

129. Lazy Load
• Virtual Proxy
– An object with the same interface as the real object
– The first time one of its methods are called it loads the real the object and then delegates

130. Lazy Load
• Value Holder
– An object with a getValue() method
– Clients call getValue() to get the real object, the first call triggers the load

131. Lazy Load
• A ghost
– The real object without any data
– The first time you call a method the ghost loads the full data into its fields

132. Lazy Load
• When to Use It
– When you have complex objects with associations with other objects
– Need to decide how much to get on a hit and how many hits we want
– Rule might be to bring in everything you need in one call
• The overhead of taking extra fields in the table is not that high
– The best time to use Lazy Load is when it involves an extra call and the data you're calling
isn't used when the main object is used

133. Chapter 12: Object Relational Structural Patterns

134. Identity Field
• What Is It: Saves a database ID field in an object to maintain identity between an in-memory object
and a database row
– In essence, Identity Field is mind-numbingly simple. All you do is store the primary key of the
relational database table in the object's fields.

135. Foreign Key Mapping
• What Is It: Maps an association between objects to a foreign key reference between tables.

136. Association Table Mapping
• What Is It: Saves an association as a table with foreign keys to the tables that are linked by the
association.

137. Dependent Mapping
• What Is It: Has one class perform the database mapping for a child class.

138. Embedded Value
• What Is It: Maps an object into several fields of another object's table.

139. Serialized LOB
• What Is It: Saves a graph of objects by serializing them into a single large object (LOB), which it
stores in a database field.

140. Single Table Inheritance
• What Is It: Represents an inheritance hierarchy of classes as a single table that has columns for all
the fields of the various classes.
– Relational databases don't support inheritance, so when mapping from objects to databases
we have to consider how to represent our nice inheritance structures in relational tables
– When mapping to a relational database, we try to minimize the joins that can quickly mount up
when processing an inheritance structure in multiple tables
– Single Table Inheritance maps all fields of all classes of an inheritance structure into a single
table.

141. Class Table Inheritance
• What Is It: Represents an inheritance hierarchy of classes with one table for each class.

142. Concrete Table Inheritance
• What Is It: Represents an inheritance hierarchy of classes with one table per concrete class in the
hierarchy

143. Inheritance Mappers
• What Is It: A structure to organize database mappers that handle inheritance hierarchies.

144. Chapter 13: Object-Relational Metadata Mapping
Patterns

145. Metadata Mapping
• What Is It: Holds details of object-relational mapping in metadata.

146. Query Object
• What Is It: An object that represents a database query.

147. Repository
• What Is It: Mediates between the domain and data mapping layers using a collection-like interface
for accessing domain objects.

148. Repository
• What Is It:
– The purpose of Repository is to encapsulate all the logic needed to obtain object references
– The Repository may store references to some of the objects. When an object is created, it
may be saved in the Repository, and retrieved from there to be used later
– If the Client requested an object from the Repository, and the Repository does not have it. It
may get it from the storage. Either way, the Repository acts as a storage place for globally
accessible objects
– The Repository may also include a Strategy. It may access one persistence storage or
another based on the specified Strategy. It may use difference storage locations for different
type of objects
• Benefits:
– The domain model is decoupled from the need of storing objects or their references

149. Repository
• How to Use It
– A Repository interface should be simple
– A Repository should have a set of methods used to retrieve objects

150. Repository
• Relationship between Factory and Repository
– The Factory is concerned with the creation of objects
– The Repository takes care of already existing objects
• The Repository may cache objects locally, but most often it needs to retrieve them from
a persistent storage
– The Repository may be seen as a Factory, because it creates objects. It is not a creation from
scratch, but a reconstitution of an object which existed. The Factory should create new
objects, while the Repository should find already created objects.
– When a new object is to be added to the Repository, it should be created first using the
Factory, and then it should be given to the Repository which will store it like in the example
below.

151. Chapter 14: Web Presentation Patterns

152. Model View Controller
• What Is It: Splits user interface interaction into three distinct roles
– Separates the UI from the logic
– MVC considers 3 roles
• Model: The domain layer handles state
• View: Presentation logic
• Controller: Connects the model and the view

153. Model View Controller
• Benefits
– Separation of the View from the domain logic in the Model. This is key in any presentation
design
• Importance of MVC
– View and Model are difference concerns
– View can change, usually the Model is the same
– Easy to test the Model without the View
• Coupling Dependencies
– View depends on the Model
– But the Model is not depending on the View

154. Model View Controller
• When to Use It
– The value is in the separation of concern
– Separating the Model and the View
– As this separtion is so fundamental in any software design, any non-trivial system should use
MVC in some form

155. Model View Controller
• MVC in Web Design
– Web Applications are request/response based
– Input Controller
1. Takes the request
2. Examines the input parameters
3. Calls the Model
4. Decides how to handle the response
5. Sends the control to the View for rendering
6. Returns the Response

156. Model View Controller
• MVC in Web Design

157. Page Controller
• What Is It: An object that handles a request for a specific page or action on a Web site

158. Front Controller
• What Is It: A controller that handles all requests for a Web site.

159. Template View
• What Is It: Renders information into HTML by embedding markers in an HTML page

160. Transform View
• What Is It: A view that processes domain data element by element and transforms it into HTML.

161. Two Step View
• What Is It: Turns domain data into HTML in two steps: first by forming some kind of logical page,
then rendering the logical page into HTML

162. Application Controller
• What Is It: A centralized point for handling screen navigation and the flow of an application

163. Chapter 15: Distribution Patterns

164. Remote Facade
• What Is It: Provides a coarse-grained facade on fine-grained objects to improve efficiency over a
network
• The facade is a thin wrapper that provider coarse-grained interface to a system
 In an OO model, you do best with small objects that have small methods
 Can cause great deal of interaction between objects and method invocations

165. Remote Facade
• How It Works:
 Allows efficient remote access with coarse-grained interface
 Facade will use the fine-grained object to build and return object like Data Transfer Object
 Should not contain any domain logic
• When to Use It
 Whenever you need remote access to fine grained object model
 Most common use is between UI and Domain Model

166. Remote Facade
• Remote method invocation are expensive
 Performance killer

167. Remote Facade
• Coarse grained interface

168. Remote Facade
• Benefits
 Net traffic is reduced
 Transactions are closer to the database
• Drawbacks
 Limitations on OOP
 Solution is based on limitations of the network

169. Data Transfer Object
• What Is It: An object that carries data between processes in order to reduce the number of method
calls.
 Object that is used to transfer data between layers
 Data Source returns data objects to web layer

170. Data Transfer Object
• How It Works:
 Similar to Value Object but is constructed to carry data between layers
 Data Source layer creates DTO for transfer
 DTOs holds data - get/set method
 Can be mutable or immutable
 Could have methods to transform data – For example serialize the data or convert to XML
 Simple Domain Objects can be used as DTO
• Creates dependencies

171. Data Transfer Object
• Assembling DTO from domain objects
 Assembler reduces dependencies
• When to Use It:
 Whenever you need to transfer multiple items of data between 2 processes in a single
method call

172. Data Transfer Object
• Pattern Overview

173. Chapter 16: Offline Concurrency Patterns

174. Optimistic Offline Lock
• What Is It: Prevents conflicts between concurrent business transactions by detecting a conflict and
rolling back the transaction

175. Pessimistic Offline Lock
• What Is It: Prevents conflicts between concurrent business transactions by allowing only one
business transaction at a time to access data.

176. Coarse-Grained Lock
• What Is It: Locks a set of related objects with a single lock.

177. Implicit Lock
• What Is It: Allows framework or layer supertype code to acquire offline locks

178. Chapter 17: Session State Patterns

179. Client Session State
• What Is It: Stores session state on the client.
• How It Works:
– Desktop applications can store the state in memory
– Web solutions can store state in cookies, hide it in web page, or use the URL
– Data Transfer Object can be used
– Session ID is the minimum client state
– Works well with REST
• When to Use It:
– Works well if server is stateless
– Maximal clustering and failover resiliency
• Drawbacks
– Does not work well for large amount of data
– Data gets lost if client crashes
– Security issues

180. Server Session State
• What Is It: Keeps the session state on a server system in a serialized form.
• How It Works:
– Session Objects – data structures on the server keyed to session ID
– Format of data can be binary, objects or XML
– Session State stored in the application server, file or local database
– Specific Implementations:
• HttpSession
• Stateful Session Beans – EJB
• When to Use It:
– It is easy to store and receive data
• Drawbacks
– Data can get lost if server goes down
– Clustering and session migration becomes difficult
– Space complexity (memory of server)
– Inactive sessions need to be cleaned up

181. Database Session State
• What Is It: Stores session data as committed data in the database.
• How It Works:
– Session State stored in the database
– Can be stored as temporary data to distinguish from committed record data
• Pending session data
– Pending session data might violate integrity rules
– Use of pending field or pending tables
• When pending session data becomes record data it is save in the real tables
• When to Use It:
– Improved scalability – easy to add servers
– Works well in clusters
– Data is persisted, even if data centre goes down
• Drawbacks
– Database becomes a bottleneck
– Need of clean up procedure of pending data that did not become record data – user just left

182. Chapter 18: Base Patterns

183. Gateway
• What Is It: An object that encapsulated access to an external system or resource

184. Mapper
• What Is It: An object that sets sup a communication between two independent objects.

185. Layer Supertype
• What Is It: A type that acts as the supertype for all types in its layer.
– Use this pattern when you have common features from all objects in a layer

186. Separated Interface
• What Is It: Defines an interface in a separate package from its implementation

187. Registry
• What Is It: A well-known object that other objects can use to find common objects and services

188. Value Object
• What Is It: A small simple object, like money or a date range, whose equality isn't based on identity
• How It Works:
– Not based on identity
– Equality is based on comparing values of the object
– Can be immutable (e.g: Date class)
• When to Use It:
– When you're basing equality on something other than identify

189. Plugin
• What Is It: Links classes during configuration rather than compilation.

190. Service Stub
• What Is It: Removes dependence upon problematic services during testing.

191. Record Set
• What Is It: An in-memory representation of tabular data.

192. References
• Patterns of Enterprise Application Architecture by Martin Fowler, David
Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford
Randy Stafford
• Domain-Driven Desing Quickly by InfoQ
• http://www.slideshare.net/olandri

193. Thanks!