ADVANCED DISTRIBUTED SYSTEMS DESIGN

WITH SERVICE ORIENTED ARCHITECTURE

Udi Dahan – The Software Simplist

Enterprise Development Expert & SOA Specialist

#ADSDcourse

www.UdiDahan.com
DISTRIBUTED SYSTEMS THEORY
SYSTEMS ARE NOT APPLICATIONS

▪ An application has a single executable and

runs on a single machine

▪ Usually has a single source of information

▪ Applications don’t know about

“connectivity”
SYSTEMS ARE NOT APPLICATIONS

▪ A system can be made up of multiple

executable elements on multiple machines

▪ Usually has multiple sources of

information

▪ System must deal with “connectivity”

SYSTEMS ARE NOT APPLICATIONS

▪ Each executable within a system is not

an application

▪ Each executable must deal with

“connectivity”
“CONNECTIVITY” – THE NETWORK MATTERS
Common assumptions made by developers and
architects in distributed systems
Deutsch 94
Gosling 97
▪ The network is reliable
▪ Latency isn’t a problem
▪ Bandwidth isn’t a problem
▪ The network is secure
▪ The topology won’t change
▪ The administrator will know what to do
▪ Transport cost isn’t a problem
▪ The network is homogeneous
“CONNECTIVITY” – THE NETWORK MATTERS
“The 8 fallacies of distributed computing”
1. The network is reliable
Deutsch 94
2. Latency isn’t a problem
Gosling 97
3. Bandwidth isn’t a problem
4. The network is secure
5. The topology won’t change
6. The administrator will know what to do
7. Transport cost isn’t a problem
8. The network is homogeneous
3 MORE FALLACIES
1. The network is reliable
2. Latency isn’t a problem
3. Bandwidth isn’t a problem
Neward 06
4. The network is secure
5. The topology won’t change
6. The administrator will know what to do
7. Transport cost isn’t a problem
8. The network is homogeneous
9. The system is atomic/monolithic
10.The system is finished
11.Business logic can and should be centralized
#1. THE NETWORK IS RELIABLE

▪ Hardware, software, security can cause issues

var svc = new MyService();

var result = svc.Process(data);

▪ How do you handle HttpTimeoutException?

Data can get lost when sent over the wire
#1. THE NETWORK IS RELIABLE
▪ Solutions:

Retry & Ack / Store & Forward / Transactions

Don’t roll your own – too many edge cases

Use reliable messaging infrastructure

MSMQ / Sql Server 2005 Service Broker

▪ But doesn’t provide a request/response

synchronous method-centric model
#2. LATENCY ISN’T A PROBLEM (==0)
▪ Time to cross the network in one direction

▪ Small for a LAN, WAN & internet can be large

Many times slower than in-memory access

▪ Bad-old days of OO – remote objects

Even accessing a property was a round-trip
Now we use DTO’s
▪ But what about lazy-loading with an ORM?
#2. LATENCY ISN’T A PROBLEM (==0)

▪ Solutions:

Don’t cross the network if you don’t have to

Inter-object chit-chat shouldn’t cross the network

If you have to cross the network,

take all the data you might need with you
#3. BANDWITH ISN’T A PROBLEM (∞)

▪ Although bandwidth keeps growing, the amount of

data grows faster

▪ When transferring lots of data in a given period of

time, network congestion may interfere

▪ ORMs eagerly fetching too much data

#3. BANDWITH ISN’T A PROBLEM (∞)

▪ Solution:

Move time-critical data to separate networks

Can’t eagerly fetch everything / can’t lazy load

everything
Might need to have more than one domain model
to resolve forces of bandwidth and latency
#4. NETWORK IS SECURE

▪ Unless you’re on a separate network that will never,

ever be connected to anything else…

▪ Well, not even then. Viruses, Trojans, etc can still be

brought in by users on CDs, DVDs, DOKs, etc

▪ You can’t be 100% safe from everything

#4. NETWORK IS SECURE

▪ Solution:

Perform a threat model analysis

Balance costs against risks

Most importantly, talk about it. Include PR and

legal.
#5. THE TOPOLOGY WON’T CHANGE

▪ Unless a server goes down and is replaced

▪ Or is moved to a different subnet

▪ Or clients wirelessly connect and disconnect

Issues with WCF callback contracts

▪ What will happen to the system when those hard

coded / config-file values change?
#5. THE TOPOLOGY WON’T CHANGE
▪ Solution:

Don’t hard-code addresses

Consider using resilient protocols (multicast)
Discovery mechanisms are cool, but hard to get right

▪ Will your system be able to maintain response-time

requirements when this happens?
#6. THE ADMIN WILL KNOW WHAT TO DO

▪ Possible in small networks

Until they get run over by a truck promoted.
Their replacement probably won’t know what to do.

▪ If there are multiple admins, rolling out various

upgrades and patches, will everything grind to a halt?
Will client software be able to work with a new
version of the server?

▪ High Availability while upgrading?

#6. THE ADMIN WILL KNOW WHAT TO DO

▪ Solution:
Consider how to pinpoint problems in production
Some logging is helpful, too much can be harmful

Consider multiple versions running in parallel

Although backwards compatibility is hard

Enable the admin to take parts of the system down

for maintenance without adversely affecting the rest
Queuing technology helps
#7. TRANSPORT COST ISN’T A PROBLEM

▪ Serialization before crossing the network (and

deserialization on the other side) takes time.
In the cloud, it can be a big cost factor

▪ The hardware network infrastructure has upfront and

ongoing costs.
#7. TRANSPORT COST ISN’T A PROBLEM

▪ Solution:

The effect of serialization on performance further

strengthen the argument to stay away from
chatting over the network

Architects need to make trade-offs between

infrastructure costs and development costs –
upfront vs. ongoing.
#8. THE NETWORK IS HOMOGENEOUS
▪ It used to be easier - .NET/Java interop works

▪ Now we’ve got Ruby, NoSQL, and stuff people

hacked together over http (a.k.a REST)

▪ Semantic interoperability will always be hard,

budget for it
#9. THE SYSTEM IS ATOMIC
▪ Maintenance is hard in “big balls of mud”
Changing one part of the system affects other parts

▪ Integration through the DB creates coupling

It gets worse with XML in the DB

▪ If the system wasn’t designed to scale out to multiple

machines, doing so may actually hurt performance
#9. THE SYSTEM IS ATOMIC
▪ Solution:

Internal loose coupling

Modularize

Design for scale out in advance, or you just may end

up being stuck with scale up.
#10. THE SYSTEM IS FINISHED
▪ Maintenance costs over the lifetime of a system are
greater than its development costs

Effort ($/T) Rewrite

“Finished” “Normal Project”

Original date

“Product”
Time

▪ The system is never “finished”

#10. THE SYSTEM IS FINISHED
▪ Solution:
There’s no such thing as a “maintenance
programmer”

Projects are a poor model for software development

Long-lived products are better

Beware the rewrite that will solve everything

A BETTER DEVELOPMENT
PROCESS
The Business IT

Requirements workarounds Business

Analyst
Rapid Prototyping

So you wish X could be better/cheaper/faster

Exactly! (still not a requirement)

A BETTER DEVELOPMENT PROCESS
The Business IT

Estimate Architect
Too broad a range

Let me do a POC for T

Go ahead with POC
New Estimate

Estimate accepted
Now it’s a requirement

Estimate: Given a well-formed team of size S

that is not working on anything else
I’m C% confident work will take between T1 & T2
A BETTER DEVELOPMENT PROCESS
The Business IT

So it’ll be ready in T2? Project

No. We’ve committed Manager
already to years of work

Reprioritize requirements
New dates

Schedule accepted
#11. BUSINESS LOGIC CAN AND
SHOULD BE CENTRALIZED
▪ “First name must be less than 40 characters”
Enforce in the UI? BL? DB? Everywhere?

What about when the business rules change?

Services

Calculation
Validation

Entities
#11. BUSINESS LOGIC CAN AND
SHOULD BE CENTRALIZED
▪ Solution:
Logic will be physically distributed
Can still “centralize” in the development view
[more reading] 4+1 views of software architecture

“Tag” source code by feature implemented

Enables finding all code by feature
Even if its in multiple files

https://github.com/Particular/Presentation.MultiDimensional
SUMMARY

▪ Best practices have yet to catch up to

“best thinking”

▪ Technology cannot solve all problems

▪ Adding hardware doesn’t necessarily help

COUPLING IN DISTRIBUTED
SYSTEMS
WHAT IS COUPLING?

▪ A measure of dependencies

▪ If X depends on Y,
there is coupling between them

▪ 2 kinds of coupling: Afferent (Ca), Efferent (Ce)

WHAT IS COUPLING?

▪ Afferent coupling (Ca) – who depends on you

Incoming coupling

▪ Efferent coupling (Ce) – on who you depend

Outgoing coupling
WHAT IS COUPLING?

▪ If X depends on Y then:

▪ X is efferently coupled to Y

▪ Y is afferently coupled to X
COUPLING – WHICH KIND IS WORSE?

Afferent (Incoming) Ef ferent (Outgoing)

A 5 0

B 0 5

C 2 2

D 0 0
HOW TO COUNT COUPLING?

X Y A B
Only one method call 3 methods,
2 properties

Same amount of coupling?

Different?
BEWARE SHARED RESOURCES

A B

DB

They hide the coupling that

otherwise would be visible
LOOSE COUPLING AT THE SYSTEMS LEVEL

▪ Minimize afferent and efferent coupling

But not mechanically

▪ Zero coupling isn’t really possible

▪ 3 Different aspects of coupling for systems:

Platform
Temporal
Spatial
COUPLING ASPECT #1: PLATFORM

▪ Also known as “Interoperability”

▪ Using protocols only available on one platform

Remoting, Binary Serialization, etc

▪ One of the 4 Tenets of Service Orientation:

“Share contract and schema, not class or type”
COUPLING ASPECT #2: TEMPORAL

Service A Service B
Synchronous Call

Waiting Working

Return

Processing time of Service B affects that of A

COUPLING ASPECT #3: SPATIAL

Service
Service A B

?
Service
B

Can communication automatically continue?

COUPLING ASPECTS:
SOLUTIONS
COUPLING ASPECT #1: PLATFORM

▪ Many options possible for interoperability.

Text-based representation on the wire (XML/JSON)
With or without schema

Use standards based transfer protocol like http

Or SMTP, UDP, etc

SOAP / WSDL / REST

ADDITIONAL PLATFORM SOLUTIONS

▪ Running Java code in-process on the CLR

▪ Running .Net code in-process on the JVM
COUPLING ASPECT #2: TEMPORAL - 1

Service A Service B

MakeCustomerPreferred(id)

Customer GetCustomerInfo(id)

Calling thread is
waiting for the
result

Save customer as preferred

Resources are held while waiting

COUPLING ASPECT #2: TEMPORAL - 2

Service A Service B

MakeCustomerPreferred(id)
YieldCustomerInfo(id)

Spawn polling thread

Got data?

Got data?
Data ready

Got data?

Save customer as preferred

Data ready but

not passed to
consumer

Resources are held while waiting. Increased load on

service B per consumer (impacted by polling interval)
COUPLING ASPECT #2: TEMPORAL - FINAL

Service A Service B

Store data Publish updated customer info

MakeCustomerPreferred(id)

Save customer as preferred

Good. By separating (in time) the inter-service

communication and the request handling
PUB/SUB TEMPORAL CONSTRAINTS

▪ Subscriber must be able to make decisions based on

somewhat stale data

▪ Requires a strong division of responsibility between

publishers and subscribers

▪ Only one logical publisher should be able to publish

a given kind of event
HOW TO DESIGN EVENTS

▪ Avoid requests/commands
Bad: “SaveCustomerRequested”

▪ State something that happened (past tense)

Subscribers shouldn’t be able to invalidate this
Good: “OrderAccepted”

▪ If you have to talk about data, state its validity

ProductPriceUpdated { Price: $5, ValidTo: 1/1/15 }
WHERE (AND WHY) NOT TO DO PUB/SUB

Service 1 Service 2

A B Service X

C
D
Service Y
E

when business requirements demand consistency

COUPLING ASPECT #3: SPATIAL

▪ Application level code should not need to know

where cooperating services are on the network

▪ Delegate communications to lower layer – the service

agent pattern
myAgent.Send(message);

▪ How does the agent know which destination to send

the message to?
LOAD BALANCING

▪ Clients talking to servers through a load balancer

don’t know which physical server is handling the
request…

▪ … as long as logically the server CAN handle the

request

▪ Routing is first logical, and second physical

COUPLING ASPECT #3: SPATIAL

▪ But if the application code doesn’t tell the agent

which logical destination to send the message to, how
would the agent know?

▪ If there was a direct mapping from message type to

logical destination, then specifying the type of
message being sent/published would be enough
MESSAGE TYPE = LOGICAL DESTINATION

▪ AddCustomerMessage:
Sent by clients to one logical server
Multiple physical servers behind a load balancer

▪ OrderCancelledEventMessage:
Published by one logical server
Multiple physical servers can publish the same

▪ Strongly-typed messages simplify routing

vs document-centric messaging
SUMMARY
▪ Loose coupling is more than just a slogan

▪ Coupling is a function of 5 different dimensions

Platform Temporal

Spatial
Afferent

Efferent
MESSAGING PATTERNS
WHY MESSAGING?

▪ Reduces afferent and efferent coupling while

increasing autonomy

▪ Reduces coupling
Use JSON/XML + AMQP for platform coupling
Use asynchronous messaging for temporal coupling
MESSAGING, COUPLING, & AUTONOMY

Schema A Schema B

Service A Service B

Communications

Service A and B don’t directly depend on each other

ASYNCHRONOUS MESSAGING

▪ It’s all about one-way, fire & forget messages

▪ Everything is built on top of it

Return Address pattern

Correlated Request/Response
Publish/Subscribe
ONE-WAY, FIRE & FORGET MESSAGING

Initiating Target
Service Service

Id
Sends, and
keeps on
working

Each message has an Id.

Seems simple, but there’s more to it.
Server
MSMQ
Outgoing Incoming

Store and
Forward

adds resilience

MSMQ
Outgoing Incoming

Client
PERFORMANCE – RPC vs MESSAGING
Throughput

Messaging

RPC

Load
▪ With RPC, threads are allocated with load
With messaging, threads are independent
Difference due to synchronous blocking calls
▪ Memory, DB locks, held longer with RPC
STANDARD SERVICE INTERFACES

Customer Service

void Change_Address(Guid id, Address a);

void Make_Preferred(Guid id);

void Change_Credit(Guid id, Credit c);

• Problem is that service layers get too large

• Difficult for multiple developers to collaborate
• Difficult to reuse logging, authorization, etc
EXPLOIT STRONGLY-TYPED MESSAGES

IMessage
where T : IMessage

IHandleMessages<T>
void Handle(T message);
REPRESENT METHODS AS MESSAGES
IMessage

Change_Address_Msg
Guid Id
Address A

Make_Preferred_Msg
Guid Id

Change_Credit_Msg
Guid Id
Credit C
HANDLING LOGIC SEPARATED
IHandleMessages<T>
void Handle(T message);

H1: IHandleMessages<Change_Address_Msg>

H2:IHandleMessages<Make_Preferred_Msg>

H3: IHandleMessages<Change_Credit_Msg>
MULTIPLE HANDLERS PER MESSAGE

H1: IHandleMessages<Change_Address_Msg>

H4: IHandleMessages<Change_Address_Msgv2>

• Dispatch based on type polymorphism

• Allows for pipeline of handler invocation
FAULT-TOLERANCE - SCENARIOS

▪ When servers crash

▪ When databases are down

▪ When deadlocks occur in the database

WHEN SERVERS CRASH

[HTTP] $$ Order
Call 1 of 3
App Tx Call 2 of 3 DB

App pool
recycle
Rollback
Where’s the order!?
WHEN DATABASES ARE DOWN

[HTTP] $$ Order Call 1 of 3

App Tx DB
Exception
Write to log Down

Where’s the order!?

WHEN DEADLOCKS HAPPEN

[HTTP] $$ Order
Call 1 of 3
App Tx Call 2 of 3 DB
Exception
Write to log A B

Where’s the order!? Deadlock

HOW DOES MESSAGING HELP?

Bus DTC Rollback

$$ Order TX Receive
Q
Invokes Enlists
Rollback Retry
Call 1 of 3
Your DB
Call 2 of 3
code

The order is back in the queue

AFTER ALL RETRIES EXHAUSTED

Retry
Append exception info
to headers*

Moved failed message Error Notify

Queue admin
a.k.a “poison letter queue”

* NServiceBus feature – not done by all queues natively

MONITORING
AUDITING / JOURNALING

▪ Sends a copy of the message to another queue

when it is processed
Supported out-of-the-box by most queues
Extract to longer-term storage
So the queue doesn’t “explode”

▪ A central log of everything that happened

▪ Can be difficult to interpret by itself

LEVERAGING MESSAGE HEADERS

Endpoint 1 Endpoint 2 Endpoint 3

Message ID: 1

Message ID: 2
Message ID: 3
Related To: 1
Related To: 2

Audit
Connect outgoing messages to ID of
message being processed
VISUALIZING THE AUDIT STORE
CALLING WEB SERVICES
Rollback

$$ Order

A B C D

Not Rolled back

[HTTP] Invoke
DB
WS Deadlock
WEB SERVICES WITH MESSAGING
The message won’t be sent if there’s a failure

$$ Order

A B C D

[HTTP] Msg
Messaging
Invoke
Gateway DB
WS
RETURN ADDRESS PATTERN

Initiating Target
Service Service

Return Address

Return Some time in

the future
Address

2 Channels: one for requests, one for responses

Server
MSMQ
Outgoing Incoming

MSMQ
Outgoing Incoming

Client
Client
CORRELATED REQUEST/RESPONSE
Based on Return Address
Initiating Target
Service Service

Message ID

Some time in
Correlation ID the future

In the header of the response message, there is a

correlation id equal to the request message id
REQUEST / MULTI RESPONSE

Initiating Target
Service Service

Responses can be of different types

SUBSCRIBE / PUBLISH

Subscriber Publisher
Subscribe

Publish

Publish

Publish

Publish
publisher subscriber

Subscribe
subscriber

subscriber

subscriber subscriber
publisher subscriber abcdefgh

abcdefgh
subscriber

abcdefgh
subscriber

subscriber abcdefgh
subscriber abcdefgh
DON’T FORGET CONSISTENCY
BOUNDARIES
Service A Service B

Store data Publish updated customer info

MakeCustomerPreferred(id)

Save customer as preferred

publisher subscriber

subscriber

Sub3 LB subscriber

subscriber
TOPIC HIERARCHIES & POLYMORPHISM

▪ Subscribe to “Products”, “Products.InStock”,

“Products.InStock.PricedToClear”

▪ Multiple-inheritance even more interesting

Publishing an event A which inherits B, C, and D
Can subscribe to any or all A, B, C, or D
Must use interfaces (not classes)
Might not be supported by standard serializers
EVENTS: IN-PROCESS VS. DISTRIBUTED

▪ In-memory, synchronous invocation

Publisher can know when all subscribers up to date

▪ Distributed, asynchronous invocation

Publisher (and other subscribers) can’t know
OUT-OF-ORDER EVENTS
Order Accepted
Sales Billing

Order Accepted

Order Billed

Now waits for OrderBilled Can’t find order in DB

which won’t arrive again Shipping Throws away the message
VISUALIZATION WITH MESSAGING

https://particular.net/blog/what-does-your-particular-system-look-like
SUMMARY
▪ Building blocks are simple
IMessage
IHandleMessages
Send, Reply, and Publish

▪ Identifying boundaries is most important

EASING CORPORATE ADOPTION
▪ People are afraid of change
▪ Meet them where they are

▪ Consider using database tables under a message-

driven API

▪ Diffuses admin/backup/monitoring objections

▪ Message-driven code is a good first step

ARCHITECTURAL STYLES
BUS & BROKER
WHAT IS AN “ARCHITECTURAL STYLE”?

An architectural style is a coordinated set of

architectural constraints that restricts the
roles/features of architectural elements and the
allowed relationships among those elements within
any architecture that conforms to that style.

Fielding 2000
WHAT IS AN “ARCHITECTURAL STYLE”?

In plain English:
What is and isn’t allowed in an architecture

Doesn’t say “there can be only one”

Should expect multiple styles in a project

- Layering, MVC, pipes & filters, etc.
WHAT TO USE WHEN?
Layers
CQRS
Pipes &
Filters
EDA DDD MVC
REST
SOA
SOA AS AN ARCHITECTURAL STYLE

▪ SOA likely to be founded on messaging

▪ It is best to first understand current styles also

founded on messaging before going to SOA
BUS & BROKER COMMONALITIES

▪ Attempt to handle spatial coupling

BROKER ARCHITECTURAL STYLE
Also known as “Hub and Spoke” and “Mediator”
Designed to avoid having to change apps – EAI

App 8 App 9 App 1

App 7 Broker App 2

App 6 App 3

App 5 App 4
BROKER CHARACTERISTICS

▪ Broker is physically separate

▪ All communication goes through the broker

▪ Broker handles fail over, routing

▪ The broker is a single point of failure, must be robust

and performant.
BROKER TECHNOLOGY

▪ BizTalk / WebSphere / Sonic ESB

▪ MS Sql Service Broker
▪ BPEL Engines
▪ CORBA
▪ UDDI
BROKER ADVANTAGES

▪ Concentrating all communications to a single logical

entity, enables central management

▪ Enables “intelligent” routing, data transformation,

orchestration

▪ Doesn’t require changes to surrounding apps

BROKER DISADVANTAGES

▪ Embodies the 11th fallacy:

“Business logic can and should be centralized”

▪ Procedural programming at a large scale

Without good unit testing or source control

▪ Prevents apps from gaining autonomy

BUS ARCHITECTURAL STYLE

▪ Event source and sinks use bus for pub/sub

▪ Designed to allow independent evolution of sources
and sinks

Source Sink

Bus

Sink Source
BUS TOPOLOGY
App App

Bus.dll Bus.dll
App App

Bus.dll Bus.dll

App App
Bus.dll Bus.dll
App App
Bus.dll Bus.dll
BUS CHARACTERISTICS

▪ Bus is not necessarily physically separate

▪ Communication is distributed
No single point of failure

▪ Bus is simpler – no content-based routing or data

transformations

▪ Orthogonal to the broker style

BROKER TECHNOLOGIES CALLED ESBS

▪ Some “New” ESB products actually brokers

WebSphere, Mule, Sonic

App 1 App 2 App 3 App 4

Voila! A bus! See, everything is at right angles!

App 5 App 6 App 7 App 8 App 9

BUS TECHNOLOGY

▪ Open-source on the Microsoft platform

NServiceBus, MassTransit, Rhino Service Bus

▪ “Old” JMS implementations / Federated AMQP

Tibco Rendezvous, RabbitMQ, Qpid
Not all support distributed / XA transactions
BUS ADVANTAGES

▪ No single point of failure

▪ Doesn’t break service autonomy

BUS DISADVANTAGES

▪ More difficult to design distributed solutions than

centralist ones
THE BEST OF BOTH WORLDS
Sales

peoplesoft biztalk

NServiceBus

BizTalk Adapter Business Logic

Data Access Logic

Billing Amdocs Shipping
3 ELEMENTS OF INTEGRATION
▪ Data transformation

XML, DB, Flat file, EDI

XBRL, WS, etc

▪ Protocol Bridging

IP*Works
Ftp, SMTP, POP, SMS
LDAP, DNS, etc

▪ Business Logic
SUMMARY

▪ Feature-rich broker products less suited to distributed

systems than robust bus products.

▪ Projects will likely use a combination of both bus and

broker
SOA BUILDING BLOCKS
WHAT IS A SERVICE?

Tenets of Service Orientation:

1. Services are autonomous.

2. Services have explicit boundaries
3. Services share contract & schema,
not class or type
4. Service interaction is controlled by policy.
SERVICE ORIENTATION

Schema A Schema B

Service A Service B

Communications
WHAT IS A SERVICE?

A service is the technical authority for a specific

business capability.

All data and business rules reside within the service.

Nothing is “left over” after identifying services

Everything must be in some service

WHAT A SERVICE IS NOT

▪ A service that has only functionality is a function

not a service.
Like calculation, validation

▪ A service that has only data is a database,

not a service.
Like [create, read, update, delete] entity

▪ WSDL / REST doesn’t change logical responsibility

4+1 VIEWS OF SOFTWARE ARCHITECTURE

▪ Services are in the logical view

▪ Mapping to the development view, a service could

be a source control repository
SERVICE EXAMPLES
Place Order

Translate status to Sales

Save pricing locally
discount & save

Subscribe to Product
Subscribe to Customer Pricing Updated
Status Updated

Publish
Product Pricing Updated
Publish
Customer Customer Status Updated Marketing
Care Publish Order Accepted
SERVICE EVENT LIFECYCLES
Business processes remain within services
Cascading events give rise to enterprise processes

Inventory Price
Replenished Changed

Order Order
Shipped Received

Customer
Billed
WHICH SERVICE OWNS THIS PAGE?
WHICH SERVICE OWNS THIS PAGE?

None
SERVICE DEPLOYMENTS

▪ Many services can be deployed to the same box

▪ Many services can be deployed in the same app

▪ Many services can cooperate in a workflow

▪ Many services can be mashed up

in the same page
SAME PAGE COMPOSITION

Product Catalog

Pricing Server

Inventory

Cross Sell
TOP-TO-BOTTOM SERVICES

UI

API

BL

DAL

DB
DEMO
ASP.NET MVC CompositeUI

bit.ly/particular-microservices
HOW TO MAKE A GRID
HOW TO MAKE A GRID
ProductNameA ProductNameB ProductNameC ProductNameD
AuthorNameA AuthorNameB AuthorNameC AuthorNameD
cover cover cover cover
image image image image
A B C D
€ 20.00 € 20.00 € 20.00 € 20.00

View
http://mydomain.com/products/123 model

Component from Component from Component from

product-catalog finance marketing

load related
products client-side message broker

Component from Component from Component from

product-catalog finance marketing
HOW TO MAKE A GRID
ProductNameA ProductNameB ProductNameC ProductNameD
AuthorNameA AuthorNameB AuthorNameC AuthorNameD
cover cover cover cover
image image image image
A B C D
€ 20.00 € 20.00 € 20.00 € 20.00

View
http://mydomain.com/products/123 model

Component from Component from Component from

product-catalog finance marketing

publish `RelatedProductsFound`
receive event

load related
products client-side message broker

Component from Component from Component from

product-catalog finance marketing
HOW TO MAKE A GRID
ProductNameA ProductNameB ProductNameC ProductNameD
AuthorNameA AuthorNameB AuthorNameC AuthorNameD
cover cover cover cover
image image image image
A B C D
€ 20.00 € 20.00 € 20.00 € 20.00

View
http://mydomain.com/products/123 model

Component from Component from Component from

product-catalog finance marketing

load related
products

Component from Component from Component from

product-catalog finance marketing
OTHER COMMON ELEMENTS

▪ Color scheme, layout, fonts, CSS, images, etc

▪ All communicate the “corporate brand”

▪ The responsibility of the “branding” service

LAYOUT IN THE BRANDING SERVICE

▪ View Models created with Whatever.js

Angular / React / Knockout / Backbone / etc

▪ Can also be done server-side

▪ Each service binds its model to part of the view

model
OR LEVERAGE CSS CLASSES

<div class=“price”>$49.99</div>
Makes it bold, red, large

<div class=“inventory.InStock>12 left</div>

Makes it bold and green

Go even farther with JS CSS preprocessors:

Mustache, LESS, Sass
PERFORMANCE OPTIMIZATION
Component Component Component
from Service from Service from Service
A B C
2. Callback 5. Callback
8.
1. Raise event 3. Call server
13. Callback 6. Call server
(callback)
(data) (callback)
14. Callback
12. Dispatches (data)
client callbacks
IT/Ops client/JS library
9. Actually calls server
4. Holds requested call in memory
7. Holds requested call in memory 10. Unpacks & dispatches requests

IT/Ops server library

11. Collects responses & returns to client

Component Component
from Service from Service
B C
ACROSS THE ENTERPRISE SERVICES
S1 S2 S3
MOBILE

BACK END

PORTAL
CONFIGURATION MANAGEMENT
an example

http://go.particular.net/octopus

http://go.particular.net/octopus-script
AMAZON.COM CHECKOUT WORKFLOW
WHICH SERVICE OWNS THIS FLOW?
WHICH SERVICE OWNS THIS FLOW?

None
WORKFLOW EVENT COMPOSITION

Sales Finance Shipping

OrderReceived

CustomerBilled

OrderShipped
WORKFLOW EVENT COMPOSITION

SetOrderId = 022032ba-1337-43a5-90c9-d48b58742c7
WORKFLOW COMPOSITION

Shipping

Sales

Billing
Billing

Sales Shipping
PARENT VS CHILDREN
Orders table
Id ShippingId FinanceId Etc
123 1337 42 …
124 1338 43 …

VS

Sales Shipping Finance

Orders table Shipping table Invoices table
Id ProductId OrderId Address OrderId Status
123 ABC 123 Haifa, Israel 123 Paid
124 ACD 124 Rotterdam, Holland 124 Overdue
PARENT VS CHILDREN
Orders table
Id ShippingId FinanceId Etc
123 1337 42 …
124 1338 43 …

VS

Sales Shipping Finance

Orders table Shipping table Invoices table
Id ProductId OrderId Address OrderId Status
123 ABC 123 Haifa, Israel 123 Paid
124 ACD 124 Rotterdam, Holland 124 Overdue

eBookShipping table BitcoinInvoices table

OrderId UrlIdentifier OrderId BitcointId
1234 03630b562df15c6 4242 1d7e565784907
1235 4c77a8e12cb1c216 4243 6561433f9245710
WHAT ABOUT THE TECHNICAL STUFF?

▪ Authentication, Authorization, etc

▪ A service should own this

shouldn’t it?
THE IT/OPERATIONS SERVICE

▪ Responsible for keeping information flowing (and

secure) in the enterprise

▪ Focused on the deployment & physical views:

Responsible for hosting (web servers, DBs, etc)
Owns connection strings, queue names

Authentication, authorization – LDAP/AD access

IT/OPS HARDLY EVER SUBSCRIBES

▪ Doesn’t really do pub/sub with other services

▪ One (rare) case

HR – employee hired, employee fired
Provisions / De-provisions machines, accounts, etc
Don’t introduce this unless necessary
INTEGRATION ENDPOINTS ( + EMAIL )

IT/Ops
DataExporter
message handler

IProvideCustomerInfo IProvideBillingInfo IProvideOrderTotal

Customer Billing Finance

Care
REPORTING – CAN BE HARDER

▪ But not that different from Composite UI grids

▪ But there is a better way:

▪ Regular reports:
Find the pattern users are looking for in the report
Model constants as domain concerns
Implement as event-correlation & send email

▪ Research / Data Science

REFERENTIAL INTEGRITY

▪ Inserting “children” without a “parent” across service

boundaries
Solved by eventual consistency

▪ Deleting – but not “cascading”

Private data – wholly inside a service. OK
Public data – shared between services. Not OK.
Eg. Deleting a product. What about orders,
inventory?
HOW DO YOU
FIND THE BOUNDARIES?
DECOMPOSING A DOMAIN

public class Customer public class Product

{ {
FirstName Name
LastName Description
Status Price
// etc // etc
} }

Customer Customer Product

FirstName Status Name
LastName Description
Product
Price
HEALTHCARE
Dentistry Service Psychology General Practitioner
PatientId Service Basic patient information
Orthodontical data Basic doctor visits
Medication

Surgery Service
PatientId
Laboratory data
Allergies information
Medication
vs

Doctors Service Patient Service

Medication Allergies
Service Service
INSURANCE Home Insurance
Home owner
Travel
Insurance
Insured persons
Coverage Coverage
PolicyId PolicyId
ClaimId ClaimId

Automotive
Insurance
Insured vehicle
Coverage
PolicyId
ClaimId

vs

Policy Service Claims Service

Home insurance Home insurance
Travel insurance Travel insurance
Automotive insurance Automotive insurance
TEAM STRUCTURE FOR SOA

IT/Ops

team team team team team

service service service service service

boundary boundary boundary boundary boundary

Branding

* Task-forces as a new/alternate model

WHEN NOT TO DO SOA
▪ Startups

▪ Generic / extensible “platforms”

SOA HOMEWORK
YOUR MISSION

▪ Identify the service boundaries

▪ What data does each service own?

▪ What part of which UI does it own?

▪ What events does it publish / subscribe to?

THE USE CASES:

▪ For a single hotel

▪ With only 1 guest per reservation

1 room per reservation

▪ No loyalty program / sign-in

ONLINE #1

▪ Search for availability

ONLINE #2

▪ Make a booking
ONLINE #2.1

▪ Make a booking
Fill in guest info
Fill in credit card
ONLINE #2.2

▪ Make a booking – additional requirements:

▪ First, authorize credit card for cancellation $$

▪ If successful, see if a room is still available
If not, release authorization, tell user “no room”

▪ Although email confirmation should be sent, result of

booking should be on next screen
ONLINE #2.2

▪ Make a booking – important domain info:

▪ Room number not allocated at time of booking

▪ Rooms not “locked” while booking in-process

▪ Capacity MUST be respected

Can’t have 50 people all book the last room
FRONT DESK #3

▪ Check-in
Find booking
by last name

Verify info

Authorize $$
for full stay

Allocate room
FRONT DESK #4

▪ Check-out
Night before:
print out bill

Guest leaves room

Person verifies

Card is charged
amount authorized
BUSINESS & AUTONOMOUS
COMPONENTS
SERVICE DECOMPOSITION

▪ The large-scale business capability that a service

provides can be further broken down

▪ “Business Components” refer to the technical elements

that implement the capability’s constituent parts
QUALITY OF SERVICE REQUIREMENTS

Order 10 Products
Sales

Order 10 Million
Products
BUSINESS COMPONENTS
Sales
Order 10
Products

Regular
Customers

Order 10 Million
Strategic Products
Customers
MORE EXAMPLES

▪ Airlines
Different counters for business class customers
▪ Shipping
Need to track temperatures for frozen goods / meat
Can use regular trucks for toilet paper
▪ Billing
Monthly invoicing for customers with an agreement
Others billed directly to credit card
BUSINESS COMPONENTS & PUB/SUB

Fulfillment Billing

Regular
Products

Order Billed
Perishable
Products
TRANSACTIONS

▪ Some kinds of messages don’t change state

▪ Other kinds of messages can get lost in case of failure

(volatile data like stock quotes)

▪ We can divide a Business Component along

transactional lines for improved performance, into
“Autonomous Components”
Transactions stay within the boundary of an AC
AUTONOMOUS COMPONENTS

▪ A Business Component is composed of one or more

Autonomous Components

▪ An Autonomous Component is responsible for one or

more message types

Composed of one or more message handlers and the

rest of the layers in the service

Is an independent package (NuGet)

AUTONOMOUS COMPONENT MAKEUP

Schema Message
Type

Multiple ACs can be

hosted together

Bus Message Common

Handler Service
endpoint
Layers
AC DEPLOYMENT INTO SYSTEMS
S1 S2 S3
MOBILE

BACK END

PORTAL
AC’S , BC’S, AND SERVICES
Service

AC DB

AC BC

AC DB

AC BC
COUPLING BETWEEN ACS

▪ Don’t try to reuse code between ACs

▪ Strive for “disposable” code

▪ Solve for today’s problem – not tomorrow’s

JFHCI
SHADES OF AUTONOMY
AC

Storage End
DB Point Msg

Shared Shared Shared Shared

Shared Own Shared Own

Own Own Own Own

SOA => BUSINESS VALUE
Order

Order
Processing

Strategic
Customers
SUMMARY
▪ Autonomous Components are the unit of packaging
in SOA – deployed into Systems.

▪ An AC takes responsibility for a specific set of

message types in the service (ideally 1).

▪ Strive to use the bus style between ACs.

SERVICE STRUCTURE
COMMAND/QUERY RESPONSIBILITY SEGREGATION
SERVICES
AC’S , BC’S, AND SERVICES Service

AC DB

AC BC

AC DB

AC BC
MULTI-USER COLLABORATION
Need to assume users are looking at stale data

Get data Get data

User is
looking at Change
stale data data
HOW MUCH DATA IS COLLABORATIVE?
SIMPLEST SOLUTION? HARDLY.
UI
Facade
Cache
BL
DAL

DB
WHY TRANSFORM BETWEEN TIERS?
Keeping the cache up to date is even more work

Cache

UI
WS
DB
Map from DTOs &
WS to view model Map from DTOs
and WS to Use ORM to map
domain objects from tables to
domain objects
SIMPLER SOLUTIONS
▪ Datasets UI through to DB
▪ Ruby on Rails

Browser
IT/Ops
authentication JSON over HTTP
and authorization
can intercept
Document DB
FACETED SEARCH
Search:
Product A
watches Consectetur adipiscing elit. Etiam in
laoreet ante. Etiam rutrum neque nec
dui consequat, in pulvinar leo porttitor.
Brand Mauris congue, arcu et semper lacinia,.

FitBit Product B
Casio Consectetur adipiscing elit. Etiam in
laoreet ante. Etiam rutrum neque nec
dui consequat, in pulvinar leo porttitor.
Mauris congue, arcu et semper lacinia,.
Style
search results
Casual Product C
Consectetur adipiscing elit. Etiam in
Luxury laoreet ante. Etiam rutrum neque nec
dui consequat, in pulvinar leo porttitor.
Mauris congue, arcu et semper lacinia,.
Price
Product D
Under $25 Consectetur adipiscing elit. Etiam in
laoreet ante. Etiam rutrum neque nec
$25 to $100 dui consequat, in pulvinar leo porttitor.
Mauris congue, arcu et semper lacinia,.
RECOMMENDATION ENGINES
ProductNameA ProductNameB ProductNameC ProductNameD
AuthorNameA AuthorNameB AuthorNameC AuthorNameD
cover cover cover cover
image image image image
A B C D
€ 20.00 € 20.00 € 20.00 € 20.00

View
http://mydomain.com/products/123 model

Component from Component from Component from

product-catalog finance marketing

load related
products client-side message broker

Component from Component from Component from

product-catalog finance marketing
HIGH CONTENTION DOMAINS
REGULAR LOGIC CHOKES
Inventory table
Id Name Quantity
42 Harry Potter 1 7
1337 Harry Potter 2 1000

begin transaction
var quantity = select Quantity from Inventory
where Id = @ProdId
if (quantity >= quantityRequested)
update Inventory
set Quantity = quantity – quantityRequested
where Id = @ProdId
commit transaction
CONNECTION POOL DRIES UP
Business needs to get flexible
Negative inventory is OK
APPEND ONLY DATAMODELS

ProductId Delta Timestamp

EventSourcing? Not quite. 1337 -5 09:03:22 17-1-2016

1337 -3 09:03:24 17-1-2016
1337 -4 09:03:25 17-1-2016
No locking 1337 -1 09:03:27 17-1-2016

Responsibility shifted 1337 +250 09:03:28 17-1-2016

1337 -4 09:03:30 17-1-2016

select sum(Delta) where…

data will expand fast!

ADD SNAPSHOTTING

ProductId Delta Timestamp

1337 +250 09:03:28 17-1-2016

begin transaction
select @quantity = sum(Delta),
TimeStamp.Before(5.min.ago)
from Inventory where Id = @ProdId
delete from Inventory where Id = @ProdId
and TimeStamp.Before(5.min.ago)
insert into Inventory @ProdId, @quantity, now()
commit transaction
...OR ATOMIC INCREMENT
network
partition

+100
-1
-3
-4
-2
CQRS THEORY
?
QUERIES
BE UP FRONT ABOUT QUERY STALENESS

Your account

Balance correct as
of 10 minutes ago
KEEP QUERIES SIMPLE
2 Layers == 2 Tiers

UI

Query only

Persistent View Model

For each view in the UI,

have a view/table in the DB

SELECT * FROM MyTable (WHERE ID = @ID)

DATA DUPLICATED, NO RELATIONSHIPS,
DATA PRE-CALCULATED
Customer Service Rep view Supervisor view
List of customers List of customers
ID Name Phone ID Name Phone Lifetime value

Rep_Customers_Table Supervisor_Customers_Table
DEPLOYMENT AND SECURITY
▪ Deploy the persistent view model DB to the web tier
(only SELECT is permitted)
Don’t have to go through the firewall – faster

▪ Role-based security
Different screens for different roles go to different
tables – SELECT permissions per role

▪ Just as secure as in-memory caches

If not more so
USE FOR PRELIMINARY VALIDATION

▪ Before going to submit data, check if it already

exists in the persistent view model

▪ Uniqueness
Can expose to user (user signup)

▪ Related Entity Existence

Address validation – existence of street name

▪ Results in less commands being rejected

!
COMMANDS
VALIDATION AND BUSINESS RULES

▪ Validation: Is the input potentially good?

Structured correctly?
Ranges, lengths, etc

▪ Rules: Should we do this?

Based on current system state
What the user saw is irrelevant
COMMAND PROCESSING LAYERS

Input from User

Validation
Rules
Persistence

DB
COMMAND PROCESSING TIERS
Transaction

Get
current
Command state
Input WS
Persist DB

Validation Validation

Rules
AMAZON.COM “ADD TO SHOPPING CART”

Shopping cart not

actually shown!

Item added
shown
(from cmd)
SHOULD WE DO WHAT THE USER ASKED?

Orders
ID Total Date Shipped Account etc etc etc
317 $37.87 1/9/09 Yes A17T5
318 $99.99 3/7/09 Yes A17T5
319 $100.11 4/8/09 Yes P313Z
320 $69.47 9/9/09 No P599Z

Save Cancel
RESERVATION SYSTEMS
RESERVATION SYSTEMS
UI BORN OF SINGLE USER THINKING

Customers line up at ticket counters

Line provides fairness
Line is invisible on the internet – we can be “unfair”
NOT CAPTURING USER INTENT
▪ In a traditional UI – the checkbox

▪ Why do users select multiple seats?

Because they’re reserving for a family / friends

▪ But then, concurrency happens

Somebody else got in first on one of the seats

▪ Try to find a block of seats somewhere else

CAPTURING USER INTENT
▪ Group reservations: people want to sit together

▪ Enter number of people

▪ Enter preferred seat type – indicates cost

▪ Emails back when reservation can be filled

Include waiting list functionality
USER POPULATION PARTITIONING

▪ VIP customers – first window of time

Want the best seats in the house
Willing to pay extra for the privilege

▪ Groups – next window of time

Want to sit together

▪ Everybody else – last window of time

Will take any free seat
SCALABILITY BENEFITS
Thousands of seats, hundreds of thousands of requests
No need to show actual status
WHAT IS A GOOD COMMAND?
▪ The kind you can reply with:

“Thank you.
Your confirmation email will arrive shortly”
OR
Just fake it in the UI

▪ Inherently asynchronous
▪ Not really related to an entity
COMMANDS VERSUS ENTITIES
▪ It’s easier to validate the command
Less data
More specific

Is this potentially good

▪ Validating large entities is complex

CQRS IN ACTION
Data from input immediately overlaid on queries

Queries
View Model
Queries
View Model
Updater

Publish
Input WS
UI
Validation Rules

DB
Commands
SUMMARY
▪ Think of reads and writes differently

▪ Reflect that difference in the schemas

▪ Design commands so that they almost can’t fail

SCALABILITY AND FLEXIBILITY
M ONITORING AND M ANAGEM ENT
NAMING QUEUES AND PROCESSES
Service

AC DB

AC BC

AC DB

AC BC
MONITORING QUEUE-BASED SYSTEMS

▪ Visibility into the number of messages in various

queues provides insight

▪ Error queue notifies admins of problems

IDENTIFYING BOTTLENECKS

# of 1000 500
A B
messages

Throughput 500 msgs/s 50 msgs/s

Total msg 2s 10 s
processing
time
Performance Counters
SO, WHICH IS WORSE?

A B
SLA SLA

100% 100%
80%
60%

T T
THE MOST IMPORTANT METRIC
B
SLA

100%

60%

Predicted time to
breach SLA
SCALABILITY

▪ We can have a number of servers each running an

instance of the same autonomous component

▪ Called the “Competing Consumers” pattern

TRADITIONAL COMPETING CONSUMER
Autonomous Component

TX receive ACI

TX receive
Autonomous TX receive
Component
Instance
on each ACI ACI
machine
COMPETING CONSUMER 2: DISTRIBUTOR
Autonomous Component

Distributor ACI

Ready

Autonomous
Component
Instance
on each ACI ACI
machine
HETEROGENEOUS SERVER FARMS

Pull

Pull Pull

Pull
VIRTUALIZATION – PART 1

▪ Connecting monitoring and scaling

▪ When time to violate SLA decreases below T, call API

to provision another vServer

▪ When time to violate SLA increases above T, call API

to deprovision a vServer

▪ Self-scaling systems are possible, given enough

capacity
FAULT TOLERANCE – HIGH LEVEL

▪ Any number of active backups

▪ Automatic load balancing

FAULT TOLERANCE – DETAILS

• In a virtualized environment, the C drive is

actually stored in a file on the SAN
VIRTUALIZATION – CONTINUED

▪ VMWare vSphere handles failover of nodes

Both for workers and distributor

▪ Consider fault-tolerant hardware (Stratus.com) for

greater than 99.999 availability
BACKUPS & DISASTER RECOVERY

▪ If you’re using a SAN:

Database data will be stored there
Queue data will be stored there

▪ Can use SAN Snapshots to get a fully consistent

system-wide backup

▪ Ship the snapshot to a disaster recover site from

time to time
VERSIONING

▪ Clients not bound to a specific server implementation

by a proxy

▪ Queues provide temporal separation

▪ Easy to swap out autonomous component

implementation without affecting clients
VERSIONING – STRATEGY
Version from “back to front”

Client Server DB

V1 V1 V1 V1

V2
V2

V2 V2
Time
ZERO-DOWNTIME UPGRADES

▪ Install v2 process alongside v1

▪ Both feeding off the same Q
ACI
▪ Check error queue v1
▪ Uninstall v1 process
▪ Go to next machine ACI
v2
▪ Automate with scripts
▪ Consider hooking into CI
SUMMARY
▪ Configuration of autonomous components enables
rich system capabilities

Flexibility
Scalability
Monitoring
Versioning
LONG RUNNING PROCESSES
WHAT IS “PROCESS”?

A process can be described as a set of activities that

are performed in a certain sequence as a result of
internal and external triggers.

▪ The most basic process control is: if-then

▪ More complex processes include state machines

WHAT IS “LONG RUNNING PROCESS”?

A long running process is a process whose execution

lifetime exceeds the time to process a single external
event or message.

▪ Long running means that multiple external

events/triggers are handled by the same process
instance – is Stateful

▪ Derived from “long-lived transactions” work in the late

80’s and early 90’s
WHY USE LONG RUNNING PROCESS?

▪ Long running processes provide a state management

facility that enables a system to encapsulate the logic
and data for handling an external stream of events.

▪ It’s just good OO programming.

INTEGRATION EXAMPLE

System A B C
Request

Store

Response
LONG RUNNING PROCESS IMPLEMENTATION

Process Queue
Send requests to 3
Request other partners

Save requests state

Response 2 Update state

Store
Check if done
Other Request

Response 3 Update state

Check if done
Other Request

Response 1 Update state + resolve

Done!
Enqueue Response or publish event
SAGAS

▪ Triggers are messages

▪ Similar to message handlers

Can handle a number of different message types

▪ Different from message handlers

Have state, message handlers don’t
Create Saga For
Start Saga Message
Message

Dispatch Message Saga

Bus
Send Saga Messages

Save Saga Saga

Persiste
r
DB Persist
Saga
Message Get Saga by Message.SagaId
4.Return Saga
2.New

Dispatch
Message Sag 3.Fill
Saga
Bus
a Persister
Complete

Saga Complete

Timeouts are
regular 1.Get Delete

Can occur on multiple messages

machines concurrently
DB
THE HARD PART

▪ The easy part is using the building blocks

▪ The hard part is analyzing the business processes to

identify what the steps should be.

▪ When interacting with legacy systems, use a saga to

manage the flow, a separate adapter for the
integration.
SIMILAR TO HEXAGONAL ARCHITECTURE
Legacy
App
Adapters
RPC

Sagas msg
msg

Logic

WS

3rd party
WS
WORKFLOW & ORCHESTRATION

▪ Orchestration is not a service by itself.

▪ Divide up workflows/orchestrations along service

boundaries
Events are published at the end of the sub-flow in a
service
Events trigger a sub-flow in other services

▪ Sagas can be used for CEP/ESP:

complex event processing, event-stream proc.
SUMMARY

▪ Use messaging building blocks to support long

running processes.

▪ Unit testing is critical for time-bound processes

▪ Keep service boundaries explicit

SERVICE LAYER
DOM AIN M ODEL INTERACTIO N S
TRADITIONAL ARCHITECTURE
BUT WHERE DO BUSINESS RULES GO?

Here?

Here?
Here?
Here?

Here?

Here?
THE BOOK
that changed everything

… and the pattern that

battles complexity…
THE DOMAIN MODEL PATTERN

Events
WHEN TO USE IT, WHEN NOT TO

▪ “If you have complicated and everchanging business

rules…”

▪ “If you have simple not-null checks and a couple of

sums to calculate, a Transaction Script is a better
bet”

p119 Patterns of Enterprise Application

Architecture
INDEPENDENT OF ALL CONCERNS

UI DB

Communications
DOMAIN MODELS MADE OF “POJO”S
public class Product
public class Customer {
{ // properties
// properties // methods
// methods }
}

public class OrderLine public class Order

{ {
// properties // properties
// methods // methods
} }

But not every bunch of POJOs is a domain model

HIGHLY TESTABLE

Test Register for

events

Call a
method

Check
properties &
event args
UNIT TEST SAMPLE

[TestMethod]
public void CreateOrderShouldConnectToCustomer()
{
Customer c = new Customer();
Order o = c.CreateOrder();

Assert.AreEqual(c, o.Customer);
}
CAN BE DEPLOYED MULTI-TIER
Different types of domain models for different tiers

SQL CLR
CONCURRENCY MODELS

Optimistic

Realistic

Pessimistic
MULTI-TABLE SPANNING TRANSACTIONS

Time TX 1 TX 2 TX 3

T0 Begin TX Begin TX Begin TX

T1 Update A Read A Update B

T2 Read B
T3 Commit Use values Commit
of A and B to
Update C

T4 Commit

Transactions can get an inconsistent picture!

REALISTIC CONCURRENCY

Need to get a current set of data

before changing anything

Get Domain Object

Ask it to update itself
Domain Object runs business rules
If successful, updates its own state
SERVICE LAYER SAMPLE CODE

public void Handle(MakeCustomerPreferredMsg m)

{
Customer c = s.Get<Customer>(m.CustomerId);
c.MakePreferred();
}

Necessary to address concurrency

DOMAIN MODEL SAMPLE : CUSTOMER

public void MakePreferred()

{
foreach(Order o in this.UnshippedOrders)
foreach(Orderline ol in o.OrderLines)
ol.Discount(10.Percent);
}

Entity relationships expose us to possible inconsistency!

REALISTIC CONCURRENCY

Some changes can be concurrent, others can’t (?)

❖ You change the customer’s address

❖ I update the customer’s credit history

❖ You cancel an order

❖ I try to ship the order

Race condition
EVEN IF THEY’RE EASY TO IMPLEMENT
public class Order
{
public void Cancel()
{
if (status != OrderStatusEnum.Shipped)
//cancel
}

public void Ship()

{
if (status != OrderStatusEnum.Cancelled)
//ship
}
}
REMEMBER

▪ In CQRS, commands don’t fail

▪ Race conditions don’t exist in business

▪ A microsecond shouldn’t change business objectives

FIND UNDERLYING BUSINESS OBJECTIVES

Rules:
1. Cannot cancel shipped orders Why?
Because shipping costs money So?
That money would be lost
if the customer cancelled Why?

Because we refund the customers money

2. Don’t ship cancelled orders
ANALYZE
▪ When an order is cancelled,
does the refund need to be given No
immediately?

▪
Yes
DIG DEEPER
What does a customer have to do
in order to get a refund?
CONSIDER SERVICE BOUNDARIES

Cancel Order Ship Products Refund Policy

Products Returned

Sales Shipping Billing

Which services require a domain model?

Refund policy driven by multiple messages
DOMAIN MODELS ARE SAGAS
BUY ITEM (IN-APP PURCHASE)

N
Pref?

Y
Calc total val of orders Calc total val of orders
in past 2 weeks in past 1 week

Val >100 Val >100

N
Y N Y

20% discount 10% discount 10% discount No discount

If balance sufficient, reduce balance & fulfill

WEB SERVICES & USER
INTERFACES
COMMON WEB ARCHITECTURE
SYNC REQUEST/RESPONSE
SCALING OUT THE WEB TIER

DB

Just shows that the DB is the bottleneck

CACHING – IN PROCESS

Keeping the cache up to date

across farms is challenging

Often requires “sticky sessions”

and that undermines load balancing
DISTRIBUTED CACHING

Not all data is kept on each node

Beware the temptation to “loop”

CACHE INVALIDATION

Reads can interfere with writes

and that hurts performance
CONTENT DELIVERY NETWORKS
Great for off-loading JS

static content IMG

CSS
ALMOST THERE…

Don’t use a smart donkey when what you need is a

AMAZON.COM
It’s all dynamic It’s all static
THE STATIC DYNAMIC WEB

* Don’t do this on your home

page
Layout.CSS Layout.JS
Dept.XML
Kindle.XML
WHAT HAPPENS OVER THE WEB?
Cached by browser
Layout.CSS
Layout.JS

Cached by ISP
Dept.XML

Cached by CDN
Kindle.XML
Nobody
even comes
knocking
PERSONALIZATION

The weather widget

• Look up location by IP
• Look up weather by location

2 back-to-back remote calls to

costly 3rd party services

Leverage cookies or browser-local storage

THANK YOU
Udi Dahan – The Software Simplist
Enterprise Development Expert & SOA Specialist