ENTERPRISE APPLICATION ARCHITECTURE

What is Architecture

Architecture is a subjective thing, a shared understanding of a system’s design by the expert developers on a project In the form of the major components and

how they interact with each other It is about decisions – decisions that

are very hard to change If it is easy to change, it is not

architectural.

Enterprise Applications

Persistent data – a lot of data Access data concurrently A lot of user interface screens Integrate with other enterprise

applications Different business processes and

conceptual dissonance Complex “business illogic”

Examples of Enterprise Apps B2C Online Retailer

Straightforward domain/business logic Very high volumes of users Easy access – web presentation

Leasing Agreement Processing System Very complex business logic No so many users Complex user interface – rich client UI Long business transactions in time

Expense-Tracking for a Small Company Not many users Simple business logic Integrate with payroll, reservation, etc

Architecture Design

There is no ONE architecture that fits all different kinds of apps

Choosing an architecture: You have to understand the particular

problem of your system and choose an appropriate design based on that understanding

The Three Principal Layers Presentation Logic

Handle the interaction between the user and the software Display information to the user Interpret commands from the user into actions

Data Source Logic Communicate with other systems

Transaction monitor DBMS

Domain Logic Business logic

Use input and stored data to produce output Decide what data sources to persist data

The Three Principal Layers Presentation is an external interface

for a service your system offers to someone else

Data source is the interface to things that are providing a service to you.

The domain normally hides the data source from the presentation

The domain and data source should never be dependent on the presentation

The Three Principal Layers Domain or presentation logic?

A test: adding a different UI, if any functionality needs to be duplicated, it should be in the domain.

Another example: If this month’s sales are 10% higher than

last month, display this month’s sales in red Domain: a method deciding if it is 10% higher Presentation: if true, highlight the sales

http://martinfowler.com/eaaDev/uiArchs.html

http://martinfowler.com/eaaDev/SeparatedPresentation.html

Deployment of the Layers

Presentation Logic Rich client: on the client HTML: on the server

Data Source Almost always on servers

Domain Logic All on the server – easy maintenance All on the client – better responsiveness Split – isolate the piece on the client

Organizing Domain Logic

Three Primary Patterns: Transaction Script Domain Model Table Model

Service Layer

Transaction Script

Suitable for systems with simple domain logic A procedure that takes the request, processes it,

stores data in DB, invokes external operations, replies back to the user

One procedure per user action/business transaction

Advantages: Easy for developers to understand Facilitate transaction boundaries

Disadvantages: Potential for duplicate code Cause tangled web of routines

Domain Model

Suitable for systems with complex logic Build a model with domain objects which

are nouns in the business Each object takes part of the logic for a

user action Advantages:

Handle complex logic in a well-organized way Disadvantages:

Hard for developers to learn Leads to complex data source layer

Table Module

Middle ground between Transaction Script and Domain Model

One table module (a class) represents a table in the DB.

Designed to work with Record Sets Advantages:

Many GUI components could use the Record Sets returned from table modules

Service Layer

Often works with Domain Model and Table Module

Placed over domain model or table module Can handle transaction control and security How much behavior in service layer:

Service layer as a façade – an API to underlying objects, or

Most business logic is in scripts in service layer and underlying objects are very simple, or

Put logic particular for a transaction or use case as transaction scripts in the layer – Controller Entity

Mapping to Relational Database Four Patterns:

Table Data Gateway Row Data Gateway Active Records Data Mapper

Behavioral Patterns: Unit of work Lazy load

Structural Mapping Patterns Structural Mapping Patterns:

Identity Field One-to-one: Foreign Key Mapping One-to-many: Foreign Key Mapping/Dependent Mapping Many-to-many: Association Table Mapping

Inheritance Single Table Inheritance

one table for the whole hierarchy Concrete Table Inheritance

one table for each concrete class including its all ancestors

Class Table Inheritance One table for each class, concrete or abstract

Web Presentation

Model View Controller Application Controller

Handle the flow of the app View Patterns

Transform View Template View Two Step View

Handle different devices

Input Controller Patterns Page Controller Front Controller

Concurrency

Offline Concurrency Concurrent control for data that’s

manipulated during multiple DB transactions Concurrency Problems

Lost Update Inconsistent read

Execution Context Request context Session context DB transaction context

Isolation and Immutability Isolation

Partition data so that any piece of it can only be accessed by one active agent

Immutable data Identify immutable data to improve

concurrency

Concurrency Control

Optimistic Locking Conflict detection

Pessimistic Locking Conflict prevention Reduces concurrency

Preventing inconsistent reads Deadlocks

Transactions

ACID Atomicity, Consistency, Isolation,

Durability Transactional Resources Reducing Transaction Isolation for

Liveness Business and System Transactions

Patterns for Offline Concurrency Control Optimistic Offline Lock Pessimistic Offline Lock Coarse-Grained Lock Implicit Lock

Application Server Concurrency

Session State

Stateless vs Stateful sessions Session State

Client Session State Server Session State Database Session State

Session Migration Session Affinity

Distribution Strategies

Distributed Objects Remote and Local Interfaces First Law of Distributed Object

Design: Don’t distribute your objects

Where you have to distribute: Client – server Server and database Web server and app server Different vendors

Working with Distribution Boundaries Remote Façade

Coarse grained objects at distribution boundaries

Data Transfer Object or Value Object Coarse grained objects need to be

transferred between the two distributed parties

Lazy Load Lazy reading data from remote services Caution: not lose any data

Interfaces for Distribution XML-based HTTP Web Service

Use it when different platforms need to talk

Synchronous Asynchronous

Putting It All Together