Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Jeppe Cramon
What SOA do you have?
Problems with SOA
• Systems are more fragile
• Development and Maintenance costs are higher
• Your services are not being ...
If you have arrived at the realization
that SOA is a pain and costs too
much without enabling business
agility or reducing...
Let’s take a trip back in time
And look at how we could do business
Sales Department
Old style SOA
Design Department Customer Department Finance Department Fabric Department
The Customer
Cre...
This is slow
We are not selling enough!!
Sales Department
Old style SOA II
Design Department Customer Department Finance Department Fabric Department
Create Sales ...
We need to speed things up!
Hackel walks between desks?
Way too slow.
We need to speed things up!
He needs to call So we make sure that
he can
Actually, call a lot!
We need to speed things up!
But Hackel still have to wait Even if we get creative
We need to speed things up!
Something
needs to be
done!!
Speed up even more!
Lets get an automatic switchboard!
Speed up even more!
New technology, same
problem
Even if we get creative
again
Or do things Async
So Hackel can send request
to Ingeborg and Kresten
which can respond to
Hackel when they’ve got an
answ...
Speed up even more!
So Kresten and Ingeborg adds more staff
Scalability is expensive
Sales Department
Design Department Customer Department Finance Department Fabric Department
Coord...
Same problem different technology
Data
Storage
Data
Storage
Data
Storage
Finance
Service
Data
Service
Design
Service
Hacke...
Resemble much?
Now back to the story…
• Scaling up Sales requires scaling up other
departments relatively much
• People cost money and wh...
Sales Department
Event Driven SOA and local caching
Design Department Customer Department Finance Department Fabric Depart...
Scalability is cheaper
Sales Department
Design Department Customer Department Finance Department Fabric Department
This is just the beginning
Have our mindset changed over
the last 40 years?
Paper work, file cabinets and manual workflows
Inventory ShippingPurchase
Manual workflow Manual workflow
Next step was automating paper forms
(aka. The birth of CRUD)
Inventory ShippingPurchase
Manual workflow Manual workflow
Database integration
Inventory ShippingPurchase
Database
Integration
Database
Integration
Enterprise Application Integration (EAI)
Inventory ShippingPurchase
Application
Integration
Application
Integration
WebServices to the Rescue?
SOA Web of Mess
Inventory
Purchase
ShippingPortal
ESB’s the the Rescue?
SOA Web of Mess hidden by ESB
Inventory
Purchase
ShippingPortal
ESB
ESB Reality
SOA Web of Mess hidden by ESB
Inventory
Purchase
ShippingPortal
ESB
I’ve got a cheaper solution
To be clear – none of the examples
represent in my opinion SOA
4 tenets of SOA:
• Boundaries are explicit
• Services share...
What we’ve seen is just old EAI
wine on new SOA bottles
Can’t we just avoid Services and
make one big application?
Retail Domain
Invoicing
Subdomain
Product
Catalog
Subdomain
Shipping
Subdomain
Sales (Order)
Subdomain
Inventory
Subdomain...
One Domain Model to Rule them All?
Combining subdomains into one big
domain model increases complexity as
everything tends...
One big model to capture it ALL?
….
…..
…..
….
…..
…..
….
…..
…..
….
…..
…..
Result: Our queries get messy
ONE MODEL TO RULE THEM ALL
ONE MODEL TO FIND THEM
ONE MODEL TO BRING THEM ALL
AND IN THE DARKNESS BIND THEM
The database determines our scalability
And databases often scale poorly
To solve the performance
problems for a few, you
have to upgrade it all
Do not design for locality and try to
distribute
Design for distribution, take advantage
of locality
Alternatively we can use Read replicas
Master Slave SlaveSlaveSlave
You’re now eventually consistent
Or introduce caching…
What’s your synchronization mechanism?
?
Many perspectives on data
Customer
Retail System
Pricing
Inventory
Sales
Product
Unit Price
Promotional Price
Promotion En...
Smaller models & clear data ownership
Sales
Product
ProductID
Name
Description
Quantity Ordered
…
Sales
Inventory
Product
...
Autonomy becomes the next
(and biggest) problem
Can you rely on others?
Data Layer
Service Orchestration issue
Data Access Layer
Service Layer
Interface/Display
Layer
System CSystem BSystem A
UI...
Service autonomy
Service B Service C
Service A
System X
Service A
System Y
Service B Service C
System X
Slow/unreliable ne...
Orchestration using synchronous
communication and local transactions
System CSystem BSystem A
UI
Service Service
DAL DAL D...
Solution for when going distributed?
Can’t we just distributed transactions?
(XA / 2 phase commit)
Distributed Transactions…. Oh my
Sales system
Sale
Delivery
system Deliveries
Customer/CR
M system Custome
r
SAP Bookkeepi...
What’s wrong with distributed transactions?
• Transactions lock resources while active
• Services are autonomous
– Can’t b...
Orchestration using synchronous
communication and without distributed transactions
System CSystem BSystem A
UI
Service Ser...
More of the same clearly can’t be
The answer…
The more autonomous services are, the
more loosely coupled they are.
Loose coupling is what drives business
agility – whic...
Loose coupling
Requires good encapsulation and
high cohesion
Return of the SILOS!!!!
We need SMALL SILOS that
SHARE very LITTLE with each other
Sales Pricing InventoryShipping
✕ ✕ ✕
A silo/bounded-context contains all parts related to it
DB Schema
Domain
Services
Application
Services
Domain
Model
Aggreg...
A silos parts are not limited to deployment
at a single location
Subdomain
User
Interface
Integration
Endpoints
(REST,
SOA...
What should our silos share?
Bounded
Context
Degrees of coupling
UI
UI
Service
ServiceData
Data Events
Events
Composite UI’s
Retail System
Sales Pricing Inventory
Web/Application
tier
Background server
tier
Storage tier
Composite UI...
Composite UI - example
Context:
Book
ISBN-10 0-321-12521-5
Composite UI - HTML
#DIV – BookReviews
#DIV – BookImage
#DIV – BookTitleAndAuthor
#DIV – BookPricing
#DIV – BookAvailabili...
Composite UI
That covers data presentation
What about transactions?
Next Step – Event Driven Architecture
Sales
Product
SKU
Name
Price
Quantity Ordered
…
Inventory Service (SAP)
Product
SKU
...
Let’s make the implicit explicit!
Old wisdom seems to have been forgotten. Let’s introduce:
Domain Events
Which:
• Signal ...
Domain Events
Events allows us to implement Business
Processes and quickly alter them
That gives us Business Agility
Introducing Choreographing Processes
Sales Service
Order
Accepted
Billing Service
Shipping
Process Manager
Shipping Servic...
Business Events
Events also allows us to decentralize data in best
Master Data Management (MDM) style where
necessary data...
MDM using Events
Note: This solution doesn’t apply the
Composite UI due to the nature of the
Systems being integrated
Sales Department
Event Driven SOA and local caching
Design Department Customer Department Finance Department Fabric Depart...
How to support an EDA
from within a Bounded Context?
Typical One size fits all ”architecture”
Client
Remote Facade
Application Service
Data Access Layer
Data Storage
Domain
Ob...
THE Solution?
Same procedure as last year?
Same procedure as every year!!!
Open to new ideas?
Paul, you idiot, what's that!?
You should only bring things we
can eat!
IT exists to support the business by
support various usecases
Usecases can be categorized as either
• ”User” intent to man...
CQS
Separation of
functions that write
&
functions that read
Functions that write are called Command methods
and must not ...
CQS
UI Application Domain Data
Commands – Change data
UI Application Data
Queries – Ask for data (no side effects)
CQS from a code perspective
public class CustomerService
{
// Commands
void MakeCustomerPreferred(CustomerId)
void ChangeC...
SO WHAT IS CQRS?
CQRS is simply the creation of two objects
where there was previously only one
Greg Young
CQRS
In its simplest form
public class CustomerWriteService
{
// Commands
void MakeCustomerPreferred(CustomerId)
void Chan...
Commands
A Command’s primary goal is to capture USER INTENT
A Command supports a single usecase and targets a
single Aggre...
Thin Layers of complexity
UI Data
Pro: Easy and simple
Con: Scales poorly for complex domains
Language of
the
database
Next step – more layers
UI Application Domain Data
Pro: Handles complex domains better by
Separating usecase and domain lo...
Anemic Domain Model
The Good parts
• All Order logic is called in ONE
class
• Lower entry level for junior
developers
The ...
We need a rich domain model
Aggregate with Order as Aggregate Root
• Order forms our Unit of consistency, which controls o...
LET’S HAVE A LOOK AT A DIFFERENT
TYPE OF ARCHITECTURE
Circular architecture
Task based
UI
Domain
ModelRead Model
1. Realization
Commands and Queries
support very different usecases
A single model cannot be
appropriate for reporting, searching
and transactional behavior
Greg Young, 2008
2. realization
Query results contain only data – no logic
• Give me the customer with his last 10 orders
• Give me the cus...
Things to think about in relation to
Queries
• Why take the pain of performing JOINS and/or
UNIONS of our nicely normalize...
So how is this relevant in the real world?
Let’s look at a real life scenario
Collaborative domains
1. Read 2. Read
4. Update
3. Coffee time
5. Stale data
We’re working with stale data
We’re always working with stale data!
20 ms
1 ms
100 ms
100 ms100 ms
1 ms
20 ms
At this point our data is at least
120 ms ...
LET’S USE STALE DATA TO OUR
ADVANTAGE BY OFFLOADING THE
DATABASE BY USING OUR READ MODELS
UI Application Domain Write
mode...
ALL WE NEED IS A GOOD WAY TO
SYNCHRONIZE OUR WRITE AND READ
MODELS
UI Application Domain Write
model
Commands – Change dat...
Let’s make the implicit explicit!
The original DDD book left out a very important concept:
Domain Events
Which:
• Signal t...
Commands & Events
• Commands mutate Aggregate state which
results in one or more Events being
issued/published.
Command Ev...
With Domain Events we now have a
mechanism to support our denormalized
View/Query models
Read model
Read model
Commands, Events and Query Models
Events
UI
Domain modelQuery model
”AcceptOrder”
command
”OrderAcce...
Messaging Architectures
Most CQRS implementations see Commands
and Events as (asynchronous) Messages
public class CreateCu...
CQRS Building blocks
Client
Commands
Command
Bus
Sends
Command
Handlers
Modify
Repositories
Read Write
Data
store
Event
Bu...
LET’S TAKE IT A STEP FURTHER
Event Sourcing
Aggregates track their own Domain Events
and derive state from them
OrderCreated ProductAdded ProductAdded ...
Full CQRS
With EventSourcing
UI Domain
Event
Store
Commands – Change data
Commands Events
SQL DB Document DB Graph DB
UI D...
public class CustomerCommandHandler {
private Repository<Customer> customerRepository;
public CustomerCommandHandler(Repos...
Testing CQRS BDD style
@Test
public void a_signedup_customer_can_unsign() {
UUID customerId = UUID.randomUuid().toString()...
CQRS / BDD Report generated based on the
previous test
Scenario: A signed-up customer can unsign
Given a Customer with id ...
SOA / Integration
Commands, Queries and Events form natural
integration interfaces
So integration is backed in from the be...
What about Scalability?
CAP Theorem
• Consistency: All nodes in the cluster see
exactly the same data at any point in time...
CAP theorem
Source: http://bit.ly/QUurnY
Strong  Weak  Eventual Consistency
ACID systems
are hard and
expensive to
scale...
BASE
Basically Available Soft-state Eventually consistent
Eventually Consistency levels:
• Causal consistency: This involv...
CQRS can give us BASE at the
architectural level through
asynchronous Commands and Events
This gives the business and IT c...
Questions?
@TigerTeamDK on TwitterEmail: jeppe@tigerteam.dk
Web: http://www.tigerteam.dk @jeppec on Twitter
What SOA do you have (with extended EDA and CQRS material)
Upcoming SlideShare
Loading in …5
×

of

What SOA do you have (with extended EDA and CQRS material) Slide 1 What SOA do you have (with extended EDA and CQRS material) Slide 2 What SOA do you have (with extended EDA and CQRS material) Slide 3 What SOA do you have (with extended EDA and CQRS material) Slide 4 What SOA do you have (with extended EDA and CQRS material) Slide 5 What SOA do you have (with extended EDA and CQRS material) Slide 6 What SOA do you have (with extended EDA and CQRS material) Slide 7 What SOA do you have (with extended EDA and CQRS material) Slide 8 What SOA do you have (with extended EDA and CQRS material) Slide 9 What SOA do you have (with extended EDA and CQRS material) Slide 10 What SOA do you have (with extended EDA and CQRS material) Slide 11 What SOA do you have (with extended EDA and CQRS material) Slide 12 What SOA do you have (with extended EDA and CQRS material) Slide 13 What SOA do you have (with extended EDA and CQRS material) Slide 14 What SOA do you have (with extended EDA and CQRS material) Slide 15 What SOA do you have (with extended EDA and CQRS material) Slide 16 What SOA do you have (with extended EDA and CQRS material) Slide 17 What SOA do you have (with extended EDA and CQRS material) Slide 18 What SOA do you have (with extended EDA and CQRS material) Slide 19 What SOA do you have (with extended EDA and CQRS material) Slide 20 What SOA do you have (with extended EDA and CQRS material) Slide 21 What SOA do you have (with extended EDA and CQRS material) Slide 22 What SOA do you have (with extended EDA and CQRS material) Slide 23 What SOA do you have (with extended EDA and CQRS material) Slide 24 What SOA do you have (with extended EDA and CQRS material) Slide 25 What SOA do you have (with extended EDA and CQRS material) Slide 26 What SOA do you have (with extended EDA and CQRS material) Slide 27 What SOA do you have (with extended EDA and CQRS material) Slide 28 What SOA do you have (with extended EDA and CQRS material) Slide 29 What SOA do you have (with extended EDA and CQRS material) Slide 30 What SOA do you have (with extended EDA and CQRS material) Slide 31 What SOA do you have (with extended EDA and CQRS material) Slide 32 What SOA do you have (with extended EDA and CQRS material) Slide 33 What SOA do you have (with extended EDA and CQRS material) Slide 34 What SOA do you have (with extended EDA and CQRS material) Slide 35 What SOA do you have (with extended EDA and CQRS material) Slide 36 What SOA do you have (with extended EDA and CQRS material) Slide 37 What SOA do you have (with extended EDA and CQRS material) Slide 38 What SOA do you have (with extended EDA and CQRS material) Slide 39 What SOA do you have (with extended EDA and CQRS material) Slide 40 What SOA do you have (with extended EDA and CQRS material) Slide 41 What SOA do you have (with extended EDA and CQRS material) Slide 42 What SOA do you have (with extended EDA and CQRS material) Slide 43 What SOA do you have (with extended EDA and CQRS material) Slide 44 What SOA do you have (with extended EDA and CQRS material) Slide 45 What SOA do you have (with extended EDA and CQRS material) Slide 46 What SOA do you have (with extended EDA and CQRS material) Slide 47 What SOA do you have (with extended EDA and CQRS material) Slide 48 What SOA do you have (with extended EDA and CQRS material) Slide 49 What SOA do you have (with extended EDA and CQRS material) Slide 50 What SOA do you have (with extended EDA and CQRS material) Slide 51 What SOA do you have (with extended EDA and CQRS material) Slide 52 What SOA do you have (with extended EDA and CQRS material) Slide 53 What SOA do you have (with extended EDA and CQRS material) Slide 54 What SOA do you have (with extended EDA and CQRS material) Slide 55 What SOA do you have (with extended EDA and CQRS material) Slide 56 What SOA do you have (with extended EDA and CQRS material) Slide 57 What SOA do you have (with extended EDA and CQRS material) Slide 58 What SOA do you have (with extended EDA and CQRS material) Slide 59 What SOA do you have (with extended EDA and CQRS material) Slide 60 What SOA do you have (with extended EDA and CQRS material) Slide 61 What SOA do you have (with extended EDA and CQRS material) Slide 62 What SOA do you have (with extended EDA and CQRS material) Slide 63 What SOA do you have (with extended EDA and CQRS material) Slide 64 What SOA do you have (with extended EDA and CQRS material) Slide 65 What SOA do you have (with extended EDA and CQRS material) Slide 66 What SOA do you have (with extended EDA and CQRS material) Slide 67 What SOA do you have (with extended EDA and CQRS material) Slide 68 What SOA do you have (with extended EDA and CQRS material) Slide 69 What SOA do you have (with extended EDA and CQRS material) Slide 70 What SOA do you have (with extended EDA and CQRS material) Slide 71 What SOA do you have (with extended EDA and CQRS material) Slide 72 What SOA do you have (with extended EDA and CQRS material) Slide 73 What SOA do you have (with extended EDA and CQRS material) Slide 74 What SOA do you have (with extended EDA and CQRS material) Slide 75 What SOA do you have (with extended EDA and CQRS material) Slide 76 What SOA do you have (with extended EDA and CQRS material) Slide 77 What SOA do you have (with extended EDA and CQRS material) Slide 78 What SOA do you have (with extended EDA and CQRS material) Slide 79 What SOA do you have (with extended EDA and CQRS material) Slide 80 What SOA do you have (with extended EDA and CQRS material) Slide 81 What SOA do you have (with extended EDA and CQRS material) Slide 82 What SOA do you have (with extended EDA and CQRS material) Slide 83 What SOA do you have (with extended EDA and CQRS material) Slide 84 What SOA do you have (with extended EDA and CQRS material) Slide 85 What SOA do you have (with extended EDA and CQRS material) Slide 86 What SOA do you have (with extended EDA and CQRS material) Slide 87 What SOA do you have (with extended EDA and CQRS material) Slide 88 What SOA do you have (with extended EDA and CQRS material) Slide 89 What SOA do you have (with extended EDA and CQRS material) Slide 90 What SOA do you have (with extended EDA and CQRS material) Slide 91 What SOA do you have (with extended EDA and CQRS material) Slide 92 What SOA do you have (with extended EDA and CQRS material) Slide 93 What SOA do you have (with extended EDA and CQRS material) Slide 94 What SOA do you have (with extended EDA and CQRS material) Slide 95 What SOA do you have (with extended EDA and CQRS material) Slide 96 What SOA do you have (with extended EDA and CQRS material) Slide 97 What SOA do you have (with extended EDA and CQRS material) Slide 98 What SOA do you have (with extended EDA and CQRS material) Slide 99 What SOA do you have (with extended EDA and CQRS material) Slide 100 What SOA do you have (with extended EDA and CQRS material) Slide 101 What SOA do you have (with extended EDA and CQRS material) Slide 102 What SOA do you have (with extended EDA and CQRS material) Slide 103 What SOA do you have (with extended EDA and CQRS material) Slide 104 What SOA do you have (with extended EDA and CQRS material) Slide 105 What SOA do you have (with extended EDA and CQRS material) Slide 106 What SOA do you have (with extended EDA and CQRS material) Slide 107 What SOA do you have (with extended EDA and CQRS material) Slide 108 What SOA do you have (with extended EDA and CQRS material) Slide 109 What SOA do you have (with extended EDA and CQRS material) Slide 110 What SOA do you have (with extended EDA and CQRS material) Slide 111 What SOA do you have (with extended EDA and CQRS material) Slide 112 What SOA do you have (with extended EDA and CQRS material) Slide 113 What SOA do you have (with extended EDA and CQRS material) Slide 114 What SOA do you have (with extended EDA and CQRS material) Slide 115 What SOA do you have (with extended EDA and CQRS material) Slide 116 What SOA do you have (with extended EDA and CQRS material) Slide 117 What SOA do you have (with extended EDA and CQRS material) Slide 118 What SOA do you have (with extended EDA and CQRS material) Slide 119 What SOA do you have (with extended EDA and CQRS material) Slide 120 What SOA do you have (with extended EDA and CQRS material) Slide 121 What SOA do you have (with extended EDA and CQRS material) Slide 122 What SOA do you have (with extended EDA and CQRS material) Slide 123 What SOA do you have (with extended EDA and CQRS material) Slide 124
Upcoming SlideShare
SOA vs EDA
Next

51 Likes

Share

What SOA do you have (with extended EDA and CQRS material)

Most companies today use SOA to integrate their systems or mobile applications, or do they?
Join me on a historical trip where we will see how integration has remained stuck in the same patterns and we will also take a look at the emperors new clothes (or SOA as it’s practiced today).
After this we will look at how to do SOA better and the principles that will make this transition possible (keywords: Event Driven Architecture, Domain Driven Design, Composite UI’s and CQRS).
Slides and Video here: http://www.tigerteam.dk/talks/IDDD-What-SOA-do-you-have-talk/

Related Books

Free with a 30 day trial from Scribd

See all

What SOA do you have (with extended EDA and CQRS material)

  1. 1. Jeppe Cramon What SOA do you have?
  2. 2. Problems with SOA • Systems are more fragile • Development and Maintenance costs are higher • Your services are not being reused • You thought SOA would solve your integration problems, but they’ve gotten worse • No one wants to build or maintain services • System performance is worse
  3. 3. If you have arrived at the realization that SOA is a pain and costs too much without enabling business agility or reducing your costs, you are not the only one. You will have to change your approach to achieve the benefits of SOA
  4. 4. Let’s take a trip back in time
  5. 5. And look at how we could do business
  6. 6. Sales Department Old style SOA Design Department Customer Department Finance Department Fabric Department The Customer Create Sales Order
  7. 7. This is slow
  8. 8. We are not selling enough!!
  9. 9. Sales Department Old style SOA II Design Department Customer Department Finance Department Fabric Department Create Sales Order
  10. 10. We need to speed things up! Hackel walks between desks? Way too slow.
  11. 11. We need to speed things up! He needs to call So we make sure that he can Actually, call a lot!
  12. 12. We need to speed things up! But Hackel still have to wait Even if we get creative
  13. 13. We need to speed things up! Something needs to be done!!
  14. 14. Speed up even more! Lets get an automatic switchboard!
  15. 15. Speed up even more! New technology, same problem Even if we get creative again
  16. 16. Or do things Async So Hackel can send request to Ingeborg and Kresten which can respond to Hackel when they’ve got an answer But even that doesn’t scale well, there’s still only one Ingeborg and Kresten
  17. 17. Speed up even more! So Kresten and Ingeborg adds more staff
  18. 18. Scalability is expensive Sales Department Design Department Customer Department Finance Department Fabric Department Coordinator Hackel
  19. 19. Same problem different technology Data Storage Data Storage Data Storage Finance Service Data Service Design Service Hackel Coordinator Service Hackel Coordinator Service Sales Order Service Sales Order Service Customer Customer Fabric Service Customer Service Data Storage Client Process Service layer Activity Service layer Data Service layer
  20. 20. Resemble much?
  21. 21. Now back to the story… • Scaling up Sales requires scaling up other departments relatively much • People cost money and why have 9 Finance people for every 10 sales people just to answer questions about pricing • There’s got to be a better way to handle this • And there is 
  22. 22. Sales Department Event Driven SOA and local caching Design Department Customer Department Finance Department Fabric Department The Customer Create Sales Order
  23. 23. Scalability is cheaper Sales Department Design Department Customer Department Finance Department Fabric Department
  24. 24. This is just the beginning
  25. 25. Have our mindset changed over the last 40 years?
  26. 26. Paper work, file cabinets and manual workflows Inventory ShippingPurchase Manual workflow Manual workflow
  27. 27. Next step was automating paper forms (aka. The birth of CRUD) Inventory ShippingPurchase Manual workflow Manual workflow
  28. 28. Database integration Inventory ShippingPurchase Database Integration Database Integration
  29. 29. Enterprise Application Integration (EAI) Inventory ShippingPurchase Application Integration Application Integration
  30. 30. WebServices to the Rescue? SOA Web of Mess Inventory Purchase ShippingPortal
  31. 31. ESB’s the the Rescue? SOA Web of Mess hidden by ESB Inventory Purchase ShippingPortal ESB
  32. 32. ESB Reality SOA Web of Mess hidden by ESB Inventory Purchase ShippingPortal ESB
  33. 33. I’ve got a cheaper solution
  34. 34. To be clear – none of the examples represent in my opinion SOA 4 tenets of SOA: • Boundaries are explicit • Services share schema and contract, not class • Service compatibility is based on policy • Services are autonomous
  35. 35. What we’ve seen is just old EAI wine on new SOA bottles
  36. 36. Can’t we just avoid Services and make one big application?
  37. 37. Retail Domain Invoicing Subdomain Product Catalog Subdomain Shipping Subdomain Sales (Order) Subdomain Inventory Subdomain Pricing
  38. 38. One Domain Model to Rule them All? Combining subdomains into one big domain model increases complexity as everything tends to be connected to and depend on everything else
  39. 39. One big model to capture it ALL? …. ….. ….. …. ….. ….. …. ….. ….. …. ….. …..
  40. 40. Result: Our queries get messy
  41. 41. ONE MODEL TO RULE THEM ALL ONE MODEL TO FIND THEM ONE MODEL TO BRING THEM ALL AND IN THE DARKNESS BIND THEM
  42. 42. The database determines our scalability
  43. 43. And databases often scale poorly To solve the performance problems for a few, you have to upgrade it all
  44. 44. Do not design for locality and try to distribute Design for distribution, take advantage of locality
  45. 45. Alternatively we can use Read replicas Master Slave SlaveSlaveSlave You’re now eventually consistent
  46. 46. Or introduce caching… What’s your synchronization mechanism? ?
  47. 47. Many perspectives on data Customer Retail System Pricing Inventory Sales Product Unit Price Promotional Price Promotion End Date Stock Keeping Unit (SKU) Quantity On Hand (QOH) Location Code Price Quantity Ordered Name The lifecycle for Data is VERY important! Forecasting?
  48. 48. Smaller models & clear data ownership Sales Product ProductID Name Description Quantity Ordered … Sales Inventory Product ProductID SKU QOH Location Code … Inventory Pricing Product ProductID Unit Price Promotional Price … Pricing DDD: Bounded Context SOA: Service Retail System Shared Entity identity
  49. 49. Autonomy becomes the next (and biggest) problem Can you rely on others?
  50. 50. Data Layer Service Orchestration issue Data Access Layer Service Layer Interface/Display Layer System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema Local transaction spanning all modules Service
  51. 51. Service autonomy Service B Service C Service A System X Service A System Y Service B Service C System X Slow/unreliable network Different SLA Slow system
  52. 52. Orchestration using synchronous communication and local transactions System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema B:Service() call C:Service() call B:DAL() call A:Service() commit() Service
  53. 53. Solution for when going distributed? Can’t we just distributed transactions? (XA / 2 phase commit)
  54. 54. Distributed Transactions…. Oh my Sales system Sale Delivery system Deliveries Customer/CR M system Custome r SAP Bookkeeping Complete Purchase Transaction Coordinator Transactional Resource Prepare Phase Commit Phase 2 Phase Commit
  55. 55. What’s wrong with distributed transactions? • Transactions lock resources while active • Services are autonomous – Can’t be expected to finish within a certain time interval • Locking keeps other transactions from completing their job • Locking doesn’t scale • X Phase Commit is fragile by design
  56. 56. Orchestration using synchronous communication and without distributed transactions System CSystem BSystem A UI Service Service DAL DAL DAL Schema Schema Schema ServiceB:Service() call C:Service() call B:DAL() call A:Service() if (A:Call-Failed?) call A:Service() if (A:Call-Failed?) Wait-A-While() call A:Service() if (A:Call-Failed-Due-To-IO?) Save-We-Need-Check-If-Call-A-Succeded-After-All AND We-Need-To-Retry call C:Service and call B:DAL AND Tell-Customer-That-This-Operation-Perhaps-Went-Well if (A:Call-Went-Well) commit()
  57. 57. More of the same clearly can’t be The answer…
  58. 58. The more autonomous services are, the more loosely coupled they are. Loose coupling is what drives business agility – which is why we wanted SOA in the first place
  59. 59. Loose coupling Requires good encapsulation and high cohesion
  60. 60. Return of the SILOS!!!!
  61. 61. We need SMALL SILOS that SHARE very LITTLE with each other Sales Pricing InventoryShipping ✕ ✕ ✕
  62. 62. A silo/bounded-context contains all parts related to it DB Schema Domain Services Application Services Domain Model Aggregates , Entities, Value Objects, Events Integration Endpoints (REST, SOAP, Pub/Sub) User Interface Silo
  63. 63. A silos parts are not limited to deployment at a single location Subdomain User Interface Integration Endpoints (REST, SOAP, Pub/Sub) Domain Services Application Services Aggregates, Entities, Val ue Objects, Ev ents DB Schema Units of individual deployment
  64. 64. What should our silos share? Bounded Context
  65. 65. Degrees of coupling UI UI Service ServiceData Data Events Events
  66. 66. Composite UI’s Retail System Sales Pricing Inventory Web/Application tier Background server tier Storage tier Composite UI UI Layered ApplicationData Access Layer Readmodel Writemodel ✕ ✕
  67. 67. Composite UI - example Context: Book ISBN-10 0-321-12521-5
  68. 68. Composite UI - HTML #DIV – BookReviews #DIV – BookImage #DIV – BookTitleAndAuthor #DIV – BookPricing #DIV – BookAvailability #DIV - Header #DIV - Body
  69. 69. Composite UI
  70. 70. That covers data presentation What about transactions?
  71. 71. Next Step – Event Driven Architecture Sales Product SKU Name Price Quantity Ordered … Inventory Service (SAP) Product SKU QOH Location Code … Pricing Service Product SKU Unit Price Promotional Price … Inventory Pricing Sales Customers Order Accepted Event MessageBus Who coordinates the sales process? Online Ordering System Web Shop (Composite UI) Sales UI
  72. 72. Let’s make the implicit explicit! Old wisdom seems to have been forgotten. Let’s introduce: Domain Events Which: • Signal that something has happened • Closely aligned to the Domain Model • Are handled by a messaging system • They are in the past tense: – CustomerBilled – ParcelShipped – CustomerCreated – ReviewCreated – CommentAdded – CommentDeleted
  73. 73. Domain Events Events allows us to implement Business Processes and quickly alter them That gives us Business Agility
  74. 74. Introducing Choreographing Processes Sales Service Order Accepted Billing Service Shipping Process Manager Shipping Service Online Ordering System MessageBus Order Accepted Order Accepted Customer Billed Customer Billed Order Ready for Shipping Order Ready for Shipping
  75. 75. Business Events Events also allows us to decentralize data in best Master Data Management (MDM) style where necessary data is cached locally in other services to break Like in the Matador example
  76. 76. MDM using Events Note: This solution doesn’t apply the Composite UI due to the nature of the Systems being integrated
  77. 77. Sales Department Event Driven SOA and local caching Design Department Customer Department Finance Department Fabric Department The Customer Create Sales Order
  78. 78. How to support an EDA from within a Bounded Context?
  79. 79. Typical One size fits all ”architecture” Client Remote Facade Application Service Data Access Layer Data Storage Domain Object Domain Object DTO DTO
  80. 80. THE Solution?
  81. 81. Same procedure as last year? Same procedure as every year!!!
  82. 82. Open to new ideas? Paul, you idiot, what's that!? You should only bring things we can eat!
  83. 83. IT exists to support the business by support various usecases Usecases can be categorized as either • ”User” intent to manipulate information • ”User” intent to find and read information We already support this in OO at a Property level: • Setter (or mutator) methods Manipulate data • Getter (or accessor) methods Read data Let’s raise it to a higher Level
  84. 84. CQS Separation of functions that write & functions that read Functions that write are called Command methods and must not return a value Functions that read are called Query methods and must have no side effects
  85. 85. CQS UI Application Domain Data Commands – Change data UI Application Data Queries – Ask for data (no side effects)
  86. 86. CQS from a code perspective public class CustomerService { // Commands void MakeCustomerPreferred(CustomerId) void ChangeCustomerLocale(CustomerId, NewLocale) void CreateCustomer(Customer) void EditCustomerDetails(CustomerDetails) // Queries Customer GetCustomer(CustomerId) CustomerSet GetCustomersWithName(Name) CustomerSet GetPreferredCustomers() } From: https://gist.github.com/1964094
  87. 87. SO WHAT IS CQRS? CQRS is simply the creation of two objects where there was previously only one Greg Young
  88. 88. CQRS In its simplest form public class CustomerWriteService { // Commands void MakeCustomerPreferred(CustomerId) void ChangeCustomerLocale(CustomerId, NewLocale) void CreateCustomer(CreateCustomer) void EditCustomerDetails(CustomerDetails) } public class CustomerReadService { // Queries Customer GetCustomer(CustomerId) CustomerSet GetCustomersWithName(Name) CustomerSet GetPreferredCustomers() } From: https://gist.github.com/1964094
  89. 89. Commands A Command’s primary goal is to capture USER INTENT A Command supports a single usecase and targets a single Aggregate Commands are stated in the imperative: – DoStuff – CreateCustomer – ShipOrder – AddComment – DeleteComment
  90. 90. Thin Layers of complexity UI Data Pro: Easy and simple Con: Scales poorly for complex domains Language of the database
  91. 91. Next step – more layers UI Application Domain Data Pro: Handles complex domains better by Separating usecase and domain logic Con: Increasing complexity. Risk of Anemic Domain model combined with transaction-script. Time Complexity Language of DTO’s Language of getters and setters Language of ORM magic
  92. 92. Anemic Domain Model The Good parts • All Order logic is called in ONE class • Lower entry level for junior developers The bad parts • Hard to test • Hard to maintain • Code dupliction • An exposed domain model is like walking around without clothes – everyone can access your private parts and violate your invariants
  93. 93. We need a rich domain model Aggregate with Order as Aggregate Root • Order forms our Unit of consistency, which controls our invariants • Order and OrderLines are created, updated and deleted together
  94. 94. LET’S HAVE A LOOK AT A DIFFERENT TYPE OF ARCHITECTURE
  95. 95. Circular architecture Task based UI Domain ModelRead Model
  96. 96. 1. Realization Commands and Queries support very different usecases
  97. 97. A single model cannot be appropriate for reporting, searching and transactional behavior Greg Young, 2008
  98. 98. 2. realization Query results contain only data – no logic • Give me the customer with his last 10 orders • Give me the customer with total sum of orders for the last year • Give me the complete order • Give me the shipping status for the order • Give me the customers last review So why go through the domain layer? UI Application Data
  99. 99. Things to think about in relation to Queries • Why take the pain of performing JOINS and/or UNIONS of our nicely normalized Relational Model? • Why not having a completely denormalized data model (or View) to support our Query? • When we completely denormalize our data, do we really need a relational database or could we use a Key/Value- or Document Store? • Do we really need our Read Data to be to the microsecond consistent with our Write data?
  100. 100. So how is this relevant in the real world? Let’s look at a real life scenario
  101. 101. Collaborative domains 1. Read 2. Read 4. Update 3. Coffee time 5. Stale data
  102. 102. We’re working with stale data
  103. 103. We’re always working with stale data! 20 ms 1 ms 100 ms 100 ms100 ms 1 ms 20 ms At this point our data is at least 120 ms stale + Thinking time + thinking time (1000-1500 ms)
  104. 104. LET’S USE STALE DATA TO OUR ADVANTAGE BY OFFLOADING THE DATABASE BY USING OUR READ MODELS UI Application Domain Write model Commands – Change data UI Application Read models Queries – Ask for data (no side effects)
  105. 105. ALL WE NEED IS A GOOD WAY TO SYNCHRONIZE OUR WRITE AND READ MODELS UI Application Domain Write model Commands – Change data UI Application Read models Queries – Ask for data (no side effects)
  106. 106. Let’s make the implicit explicit! The original DDD book left out a very important concept: Domain Events Which: • Signal that something has happened • Closely aligned to the Domain Model • Are handled by a messaging system • They are in the past tense: – CustomerBilled – ParcelShipped – CustomerCreated – ReviewCreated – CommentAdded – CommentDeleted
  107. 107. Commands & Events • Commands mutate Aggregate state which results in one or more Events being issued/published. Command Event(s) AcceptOrder OrderAccepted ShipOrder OrderShipped AddComment CommentAdded QuarantineReview ReviewQuarantined UnquarantineReview ReviewUnquarantined
  108. 108. With Domain Events we now have a mechanism to support our denormalized View/Query models
  109. 109. Read model Read model Commands, Events and Query Models Events UI Domain modelQuery model ”AcceptOrder” command ”OrderAccepted” event ”Find all Accepted Orders” Query Commands are Imperative: DoStuff Events are Past tense: StuffDone
  110. 110. Messaging Architectures Most CQRS implementations see Commands and Events as (asynchronous) Messages public class CreateCustomer { public final Guid CustomerId; public final Name CustomerName; … } public class CustomerCreated { public final Guid CustomerId; public final DateTime CreationDateTime; public final Name CustomerName; } Command Event Difference: INTENT
  111. 111. CQRS Building blocks Client Commands Command Bus Sends Command Handlers Modify Repositories Read Write Data store Event Bus Command Services Event Handlers Events Read store Query HandlersQuery Results Queries Query Services Events Domain
  112. 112. LET’S TAKE IT A STEP FURTHER
  113. 113. Event Sourcing Aggregates track their own Domain Events and derive state from them OrderCreated ProductAdded ProductAdded ProductRemoved ProductAdded OrderAccepted Time 07:39 Time 07:40 Time 07:41 Time 07:45 Time 07:46 Time 07:50
  114. 114. Full CQRS With EventSourcing UI Domain Event Store Commands – Change data Commands Events SQL DB Document DB Graph DB UI Data Queries – Ask for data Events Query Build Our single source of truth
  115. 115. public class CustomerCommandHandler { private Repository<Customer> customerRepository; public CustomerCommandHandler(Repository<Customer> customerRepository) { this.customerRepository = customerRepository; } @CommandHandler public void handle(UnsignCustomer cmd) { Customer customer = repository.load(cmd.getCustomerId()); customer.unsign(); } } public class Customer { private boolean signedUp; public void unsign() { if (signedUp) { apply(new CustomerUnsignedEvent()); } } @EventHandler private void handle(CustomerUnsignedEvent event) { signedUp = false; } }
  116. 116. Testing CQRS BDD style @Test public void a_signedup_customer_can_unsign() { UUID customerId = UUID.randomUuid().toString(); FixtureConfiguration fixture = Fixtures.newGivenWhenThenFixture(); fixture.registerAnnotatedCommandHandler( new CustomerCommandHandler(fixture.createGenericRepository(Customer.class)) ); fixture.setAggregateIdentifier(customerId); fixture .given( TestFactory.customerCreatedEvent(customerId), TestFactory.customerSignedUpEvent(customerId) ) .when( TestFactory.unsignCustomerCommand(customerId) ) .expectEvents( TestFactory.customerUnsignedEvent(customerId) ); }
  117. 117. CQRS / BDD Report generated based on the previous test Scenario: A signed-up customer can unsign Given a Customer with id ”abc1234” that has been created and a customer with id ”abc1234” that is signed-up When a request for Customer with id ”abcd1234” to be unsigned is received Then the Customer with id ”abcd1234” is unsigned
  118. 118. SOA / Integration Commands, Queries and Events form natural integration interfaces So integration is backed in from the beginning!
  119. 119. What about Scalability? CAP Theorem • Consistency: All nodes in the cluster see exactly the same data at any point in time • Availability: Failure of a node does not render the entire system inoperative • Partition tolerance: Nodes can still function when communication with other groups of nodes is lost You can’t have all three!
  120. 120. CAP theorem Source: http://bit.ly/QUurnY Strong  Weak  Eventual Consistency ACID systems are hard and expensive to scale Latency concerns Unless you use Pessimistic Locking – all data is stale (and eventual consistent when delivered to the user)
  121. 121. BASE Basically Available Soft-state Eventually consistent Eventually Consistency levels: • Causal consistency: This involves a signal being sent from between application session indicating that a change has occurred. From that point on the receiving session will always see the updated value. • Read your own writes: In this mode of consistency, a session that performs a change to the database will immediately see that change, even if other sessions experience a delay. • Monotonic consistency: In this mode, A session will never see data revert to an earlier point in time. Once we read a value, we will never see an earlier value. See http://www.allthingsdistributed.com/2008/12/eventually_consistent.html for more
  122. 122. CQRS can give us BASE at the architectural level through asynchronous Commands and Events This gives the business and IT control over where to spend money to scale our solution - instead of trying to buy a bigger database server.
  123. 123. Questions? @TigerTeamDK on TwitterEmail: jeppe@tigerteam.dk Web: http://www.tigerteam.dk @jeppec on Twitter
  • zgdhj95

    Nov. 28, 2017
  • angelaboyd2008

    Sep. 13, 2017
  • IonutMandra

    Jan. 5, 2017
  • AnkushBorse

    Nov. 26, 2016
  • RodolphLecocq

    Sep. 15, 2016
  • durgasubburaman

    Sep. 6, 2016
  • ranga_in

    Sep. 6, 2016
  • believe3301

    Aug. 18, 2016
  • powerirs

    Jul. 15, 2016
  • chimchich

    Apr. 20, 2016
  • javalai

    Dec. 8, 2015
  • favoorr

    Nov. 11, 2015
  • MargusPrnsalu

    May. 26, 2015
  • vicchow

    May. 18, 2015
  • budibudifr

    Apr. 12, 2015
  • fasoulas

    Mar. 28, 2015
  • joobn

    Mar. 21, 2015
  • greg2502

    Mar. 10, 2015
  • savanete

    Feb. 20, 2015
  • AmbroseMungai

    Feb. 6, 2015

Most companies today use SOA to integrate their systems or mobile applications, or do they? Join me on a historical trip where we will see how integration has remained stuck in the same patterns and we will also take a look at the emperors new clothes (or SOA as it’s practiced today). After this we will look at how to do SOA better and the principles that will make this transition possible (keywords: Event Driven Architecture, Domain Driven Design, Composite UI’s and CQRS). Slides and Video here: http://www.tigerteam.dk/talks/IDDD-What-SOA-do-you-have-talk/

Views

Total views

11,706

On Slideshare

0

From embeds

0

Number of embeds

4,245

Actions

Downloads

0

Shares

0

Comments

0

Likes

51

×