Software Construction & Design 1
The University of Sydney Page 1
Software Design and
Construction 2
SOFT3202 / COMP9202
Enterprise Application
Architecture Design Patterns
School of Information Technologies
Dr. Basem Suleiman
The University of Sydney Page 2
Copyright Warning
COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
WARNING
This material has been reproduced and communicated to
you by or on behalf of the University of Sydney
pursuant to Part VB of the Copyright Act 1968 (the
Act ).
The material in this communication may be subject
to copyright under the Act. Any further copying or
communication of this material by you may be the
subject of copyrightprotection under
the Act.
Do not remove this notice.
The University of Sydney Page 3
Agenda
– Enterprise Application Architecture
– Layered Architecture
– Enterprise Application Design Patterns
– Unit of work
– Lazy load
– Value Object
The University of Sydney Page 4
Enterprise Applications
Architecture
The University of Sydney Page 5
Catalogue of Design Patterns
Design Pattern Description
Gang of Four (Gof) First and most used. Fundamental patterns OO development, but not
specifically for enterprise software development.
Enterprise Application
Architecture (EAA)
Layered application architecture with focus on domain logic, web,
database interaction and concurrency and distribution. Database
patterns (object-relational mapping issues)
Enterprise Integration Integrating enterprise applications using effective messaging models
Core J2EE EAA Focused on J2EE platform. Applicable to other platforms
Microsoft Enterprise
Solution
MS enterprise software patterns. Web, deployment and distributed
systems
https://martinfowler.com/articles/enterprisePatterns.html
https://martinfowler.com/articles/enterprisePatterns.html
The University of Sydney Page 7
Enterprise Applications
– Payroll, patient records, shipping tracking, insurance, accounting, insurance
– Involve lots of data
– Information systems or data processing
– Managing very large data using DBMS
– Data must be persistent (for many years even with SW/HW changes)
– Concurrent data access (web-based) require transaction management
– Data needs to be presented differently to end users
– Enterprise applications need to integrate with other applications
The University of Sydney Page 8
Enterprise Applications
– Enterprise applications need to integrate with other applications
– Developed using different technologies
– Data files, DBMS, communication among components
– Differences in business processes
– Complex business logic/rules
– Customer (one with current agreement or had a contract)
– Product sales vs service sales
– Different enterprise application types impose different design challenges
The University of Sydney Page 9
Enterprise Applications – Layered Architecture
– .
https://commons.wikimedia.org/wiki/File:Overview_of_a_three-tier_application_vectorVersion.svg#/media/File:Overview_of_a_three-
tier_application_vectorVersion.svg
The University of Sydney Page 10
Enterprise Applications – Principal Layers
Layer Description
Presentation Handle interactions between the user and the
application
Domain/Business
logic
Application logic including calculations based on
inputs, retrieving and storing data from the data
source
Data Source Storing persistence data. Works with other systems
such as transaction monitors and messaging system
The University of Sydney Page 11
Enterprise Applications – Layered Architecture
– .
The University of Sydney Page 12
Layering – Architectural Decision
– Performance is a significant design decision
– Response time: amount time it takes for the system to process a request
– Throughput: amount of work an application can handle in a given amount
of time
• Bytes per seconds, requests per second, transaction per second
– Other measures related to performance include responsiveness, latency,
scalability
The University of Sydney Page 13
Layering – Architectural Decision
– Many factors can influence performance while designing enterprise
applications
– Communication among different components
• Trips over the wire (networking)
• Communication styles (messaging, RPCs)
– System resources (memory, disk)
– Expensive system operations (database read/write)
– Sharing and concurrency
The University of Sydney Page 14
Mapping Objects to Database
– Data is modeled as objects in the domain model
but as tables (e.g., in RDB)
– Objects stored in-memory
– Tables stored persistently a database
– Issue: how to do mapping between in-memory
objects and database tables
The University of Sydney Page 15
What is a Transaction?
– Database technology allows application to define a transaction
– A segment of code that will be executed as a whole
– System infrastructure should prevent problems from failure and concurrency
– Transaction should be chosen to cover a complete, indivisible business
operation
– Book a seat
– Transfer money
– Withdraw cash
– Sell something
– Borrow a book
The University of Sydney Page 16
Transaction – ACID
– The transaction support should pass the ACID test
– Atomic (all, or nothing)
• Either transaction commits (all changes are made) or else it aborts (no changes
are made)
• Abort may be application-requested rollback, or it may be system initiated
– Consistent
– Isolated (no problems from concurrency; details are complicated)
• DBMS provides choices of “isolation level”
– Usually good performance under load is only available with lower isolation
– But lower isolation level does not prevent all interleaving problems
– Durable (changes made by committed transactions are not lost in failures)
The University of Sydney Page 17
Unit of Work
Object Relational Behavioural Pattern
The University of Sydney Page 18
Unit of Work Pattern
“Maintains a list of objects affected by a business transaction
and coordinates the writing out of changes and the resolution
of concurrency problems”
The University of Sydney Page 19
Unit of Work – Applicability
– Want to keep track of everything during a business transaction that can
affect the database
– Pulling data from a database
– Insert new objects you create and remove any objects you delete
– Might be useful with session objects
– Why not changing the database with each change to the object
model?
The University of Sydney Page 21
Unit of Work – Applicability
– Batch updates
– Multiple database updates as a unit
– One remote call rather than multiple
– JDBC allow such facility
– Any transactional resource not just databases
The University of Sydney Page 22
Unit of Work – How it Works
– Notify UoW of any change including:
– New object created
– Existing objects updated (modified/deleted)
– Existing objects being read (to ensure consistency)
– When a transaction has to be committed, UoW:
– Open a transaction
– Check concurrency (pessimistic/optimistic offline lock)
• Why not programmers make explicit database updates?
– Write changes out to the database
– Needs to know objects it should keep track of
– By caller or through the object itself
The University of Sydney Page 23
UoW – Caller Registration
– UoW needs to know what
objects it should keep track
of
– This can be realized by
Caller Registration
The University of Sydney Page 24
UoW – Object Registration
– UoW needs to know what
objects it should keep track
of
– This can be realized by
Object Registration
The University of Sydney Page 25
UoW – as Controller
– .
The University of Sydney Page 26
Unit of Work – Consequences
– Keep all information in one place
– Reduce number of database calls
– Handle business operation that span several transactions
– Alternatives can be impractical or difficult to manage
– Save any object whenever is changed
– Use variables to track objects that change
– Setting and finding objects through a special flag (dirty flag)
The University of Sydney Page 27
Lazy Load
Object Relational Behavioural Pattern
The University of Sydney Page 28
Lazy Load
“An object that doesn’t contain all of the data you need but
knows how to get it.”
The University of Sydney Page 29
Lazy Load – Applicability
– Depends on how much data need to retrieve from the database and how
many calls required to achieve that
– When the field requires extra database call(s)
– When you need to retrieve everything in one call, especially if it
corresponds to a single interaction
– Not useful when a field is stored in the same row as the rest of the object
The University of Sydney Page 30
Lazy Load – How it Works
– Four ways to implement Lazy Load:
– Lazy initialization
– Virtual Proxy
– Value Holder
– Ghost
The University of Sydney Page 31
Lazy Load – Lazy Initialization
– Use “null” to indicate That a field has not been loaded
– Every access to the field requires a “is-null” check
– A field with null means the value will need to be calculated before returning
the field
– The field should be self-encapsulated
– Access through getting method
– Use another check in case null is a legal field value
The University of Sydney Page 32
Lazy Initialization – Implementation
– Access of the products field for the first time cases the data to be loaded
from the database
The University of Sydney Page 33
Lazy Load – Virtual Proxy
– Object that looks like the object that should be in the field but it doesn’t
contain anything
– Virtual Proxy looks like exactly the same object suppose to be there
– Object identities issue
– Multiple virtual proxies (with different identities) for the same real object
– Dealing with many virtual proxies instatically-typed languages
The University of Sydney Page 34
Virtual Proxy – Implementation (1)
– List of products for a supplier to be held with a regular list field
– List proxy setup to provide the list that has to be created when it’s accessed
The University of Sydney Page 35
Virtual Proxy – Implementation (2)
– Virtual list instantiation with a loader that calls the appropriate loader
The University of Sydney Page 36
Virtual Proxy – Implementation (3)
– Product loader assignment to the list field
The University of Sydney Page 37
Virtual Proxy – Implementation (4)
– Evaluate the loader on the first reference
The University of Sydney Page 38
Virtual Proxy – Implementation (5)
– Regular list methods
The University of Sydney Page 39
Lazy Load – Value Holder
– An object that wraps some other object
– To get the underlying object, ask the value holder for its value on the first
access
– Lose explicit strong typing
– Class needs to know that it is present
– To avoid identity problems, ensure that the value holder is never passed out
beyond its owning class
The University of Sydney Page 40
Lazy Load – Ghost
– A real object in a partial state
– An object where every field is lazy-initialized in one go
– When an object is loaded from the database it contains just its ID. It’s full
state is loaded whenever an access to its filed is attempted
The University of Sydney Page 41
Lazy Load – Consequences (1)
– Virtual proxy/ghost can hold some data
– Data quick to retrieve and commonly used
– Issues with inheritance (in statically typed languages)
– Can’t decide the type of ghost/virtual proxy to create until the object is
loaded properly
– Lazy load may lead to database access more than needed
– Collection with lazy loads and read them one at a time (ripple loading)
– Make the collection itself as a lazy load and load all the contents
– That doesn’t scale with very large collections
The University of Sydney Page 42
Lazy Load – Consequences (2)
– Dealing with different degrees of laziness (which subset of the object fields is
needed)
– Use separate database interaction objects (one for each common scenario)
– E.g., two order mapper objects; one that loads line items immediately and one
loads it lazily
– More varieties of laziness, complexity overweight benefits
– Practically two: complete load and just enough load for identification
The University of Sydney Page 43
Value Object
Object Behavioural
The University of Sydney Page 44
Value Object
– What is the difference between value object and reference objects? Give
examples
The University of Sydney Page 47
Value Object
– “A small simple object whose equality isn’t based on identity”
– Applicability
– When you want to use equality on something other than identity
The University of Sydney Page 48
Value Object Example – Money
– Money represents a monetary value
– Many issues such as
– Multiple currencies: e.g., cannot add dollars to yen
– Rounding errors: losing cents/pennies
The University of Sydney Page 49
Value Object – Example
– Fields should be defined appropriately
– The amount as integral or a fixed decimal type – a float
type might introduce rounding problems
– Monetary values either rounded to the smallest complete unit or with
fractional units
– Arithmetic operations should be currency-aware
– Addition and subtraction
– Rounding issues in division and multiplication
– E.g.,to add %5 tax, multiply it by 0.05
The University of Sydney Page 50
Value Object Example – Money
– Business rule: allocate the whole amount of a sum
of money to 2 accounts:
– 70% to Acc1 and
– 30% to Acc2
– How would an application allocate 5 cents?
The University of Sydney Page 51
Value Object Example – Money
– Allocator function
– Take ratio parameter as a list of numbers
– Returns list of monies without dropping scents
– A rule to enforce how to deal with allocation
The University of Sydney Page 52
Value Object Example – Money
– Currency conversion
– Simple solution Multiply by exchange rate
– But there might be some rounding issues – conversion rules may have
specific rounding
– Instead use converter object to encapsulate the conversion algorithm
– Money comparison
– Compare different currencies require currency conversion
The University of Sydney Page 53
Value Object Example – Money
– How to storing money in a database?
– As embedded value; currency for every money?
– Store the currency on the account and pull it whenever you load entries
– How to display money on a UI?
– Use printing behavior to display the correct amount with appropriate
currency
The University of Sydney Page 54
Money Example – Implementation
The University of Sydney Page 55
Money Example – Implementation
– Access the underlying data (amount)
– Accessors
The University of Sydney Page 56
Money Example – Implementation
– Money equality
The University of Sydney Page 57
Money Example – Implementation
– Money equality
The University of Sydney Page 58
Money Example – Implementation
– Money Addition
The University of Sydney Page 59
Money Example – Implementation
– Money comparison
The University of Sydney Page 60
Money Example – Implementation
– Money Multiplication
The University of Sydney Page 61
Money Example – Implementation
– Allocate sum of money among many targets without losing cents
The University of Sydney Page 62
Value Object – Consequences
– Performance improvements
– Specifically with binary serializing
The University of Sydney Page 63
Lazy Loader – Value
Holder Implementation
The University of Sydney Page 64
Value Holder – Implementation (1)
– Product field typed as a value and use getProducts() to hide this from the
clients
The University of Sydney Page 65
Value Holder – Implementation (2)
– Value holder performs
the lazy initialization
The University of Sydney Page 66
Value Holder – Implementation (3)
– Value holder performs the lazy initialization
The University of Sydney Page 67
Unit of Work –
Implementation
The University of Sydney Page 68
Unit of Work – Implementation (1)
– Unit of work that can track all changes for a given business transaction and then
commit them to the database when required
– Registration methods
The University of Sydney Page 69
Unit of Work – Implementation (2)
– Registration methods
The University of Sydney Page 70
Unit of Work – Implementation (3)
– Commit method to locate data mapper for each object and invoke appropriate
mapping method
The University of Sydney Page 71
Unit of Work – Implementation (4)
– Facilitate object registration
The University of Sydney Page 72
Unit of Work – Implementation (5)
– Methods to register objects as unit of work
The University of Sydney Page 73
Unit of Work – Implementation (5)
– Domain objects need to mark themselves new and dirty where appropriate
The University of Sydney Page 74
Unit of Work – Implementation (6)
– Register and commit unit of work
The University of Sydney Page 75
References
– Martin Fowler (With contributions from David Rice, Matthew
Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford).
2003. Patterns of Enterprise Applications Architecture. Pearson.
– Enterprise-Scale Software Architecture (COMP5348). Slides
2018.
The University of Sydney Page 76
W8 Tutorial: Practical
Exercises/coding + quiz
W8 Lecture: Enterprise Design
Patterns
Design Pattern Assignment
Reviews
There are no reviews yet.