Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Araf	Karsh	Hamid	:	Co-Founder	&	CTO,	MetaMagic	Global	Inc.,	NJ,	USA
Part	2	:	Event	Sourcing	and	Distributed	Transactions	f...
11/1/17 2
Agenda
1. Micro	Services	Characteristics
2. Micro	Services	System	Design	Model
3. Monolithic	Vs.	Micro	Services	...
Micro	Services	Characteristics
3
1.1
By	James	Lewis	and	Martin	Fowler	
We	can	scale	our	operation	independently,	maintain	...
Micro	Services	System	Design	Model
Service	
(Micro)
Process	&	
Tools
CultureOrganization
Solution	
(Macro)
11/1/17 4
Servi...
11/1/175
Monolithic	vs.	Micro	Services	Example
Traditional	Monolithic	App	using	
Single	Technology	Stack
Micro	Services	wi...
11/1/17
6
SOA	vs.	Micro	Services	Example
Traditional	Monolithic	App	with	SOA	
Micro	Services	with	Multiple	Technology	Stac...
Scale	Cube	and	Micro	Services
11/1/17 7
1. Y	Axis	Scaling	– Functional	Decomposition	:	Business	Function	as	a	Service
2. Z...
1	November	2017 8
Design	Patterns
Single	
Component	
Pattern
A	Component	shall	do	ONLY	one	thing,	
But	do	it	in	FULL.
Sing...
Summary	– Micro	Services	Intro	
11/1/17 (C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 9
Benefits
1. Robust
2. Scala...
11/1/17 10
1. Event	Sourcing	Intro
2. Domain	Events	and	Integration	Events
3. Event	Sourcing	&	CQRS	Implementations
4. Min...
Event	Sourcing	Intro
11/1/17 11
Standard	CRUD	Operations	– Customer	Profile	– Aggregate	Root
Profile	Created Title	Updated...
Domain	Events	&	Integration	Events
11/1/17 12
1. Domain	Events	represent	something	happened	in	a	specific	Domain.	
2. Doma...
(C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA
Event	Sourcing	and	CQRS	Implementation
Command	
Handler
Function	1
Fu...
Mind	Shift	:	From	Object	Modeling	to	Process	Modeling	
11/1/17 14
2.4
Developers	with	Strong	Object	Modeling	experience	
w...
App	User’s	Journey	&	Bounded	Context	(DDD)
11/1/17
15
2.4
1
An	App	User’s	Journey	can	run	across	
multiple	Bounded	Context...
Business	Solution	&	Business	Process
11/1/17 (C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 16
2.4
2
q Business	Solu...
Ubiquitous	Language : Understanding	Requirement	Analysis	using	DDD
1	November	2017 17
Ubiquitous
Language
Vocabulary share...
Capability	Centric	Design	
11/1/17 18
2.4
4
Front-End
Back-End
Database
Business	
Capability	1
Front-End
Back-End
Database...
11/1/17 (C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 19
11/1/17
(C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 20
Process
• Define	your	Business	Processes.	Eg.	Various	aspe...
Event	Storming	:	Restaurant	Dining	Example	– Customer	Journey
11/1/17 21
Order	 Payment
• Add	Drinks
• Add	Food
• Update	F...
Event	Storming	Process	map	– Concept	
11/1/17 22
1. Define	your	User	Journey.User	Journey
2.7
DE
IE
Domain	
Events
Integra...
Table	OpenedOpen	TableC DE
11/1/17
23
ESP	:	Customer’s	Dinning	Journey	:	1–of–3
Actions Micro	Service Events ES	Aggregate
...
11/1/17 24
ESP	:	Customer’s	Dinning	Journey	:	2–of–3
Actions Micro	Service Events ES	Aggregate
2.8
2 3 4
Table	ClosedClose...
Payment	StatusProcess	PaymentC IE
11/1/17 25
ESP	:	Customer’s	Dinning	Journey	:	3–of–3
Actions Micro	Service Events ES	Agg...
Summary	– ESP	:	Event	Sourcing	Process	map	
11/1/17 26
Process1
Commands2
Projections5
ES	Aggregate4
Events3
User	Journey	...
11/1/17 27
1. ACID	Vs.	BASE
2. CAP	Theorem
3. Distributed	Transactions	:	2	Phase	Commit
4. Scalability	Lessons	from	eBay
S...
ACID	Vs.	BASE
ACID
Atomic
◦ All	operations	in	a	transaction	succeed	or	every	
operation	is	rolled	back.
Consistent
◦ On	th...
CAP	Theorem	by	Eric	Allen	Brewer
1	November	2017
29
Pick	Any	2!! Say	NO	to	2	Phase	Commit		J
Source:		https://en.wikipedia...
Distributed	Transactions	:	2	Phase	Commit
2	PC	or	not	2	PC,	Wherefore	Art	Thou	XA?
1	November	2017
30
How	does	2PC	impact	...
Scalability	Best	Practices	:	Lessons	from
Best	Practices Highlights
#1 Partition	By	Function
• Decouple	the	Unrelated	Func...
Summary	:	Scalability	Requirement	in	Cloud
11/1/17 (C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 32
1. Availability...
11/1/17 (C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 33
1. SAGA	Introduction
2. SAGA	Features
3. Local	SAGA	Featur...
SAGA	Design	Pattern	Introduction
11/1/17 34
Long	Lived	Transactions	(LLTs)	hold	on	to	DB	resources	for	relatively	long	per...
SAGA	Features
11/1/17 35
1. Backward	Recovery	(Rollback)
T1 T2		T3 T4 C3 C2 C1
Order	Processing,	Banking	
Transactions,	Ti...
Local	SAGA	Features
11/1/17 36
1. Part	of	the	Micro	Services
2. Local	Transactions	and	Compensation	
Transactions
3. SAGA	...
SAGA	Execution	Container
11/1/17 37
1. SEC	is	a	separate	Process
2. Stateless	in	nature	and	Saga	state	is	stored	in	a	
mes...
Let-it-Crash	Design	Pattern	– Erlang	Philosophy	
11/1/17 38
• The	Erlang	view	of	the	world	is	that	everything	is	a	process...
Let-it-Crash	Design	Pattern
11/1/17 39
1. The idea of Messages as the first class citizens of a system, has been
rediscove...
Let-it-Crash	:	Comparison	Erlang	Vs.	Micro	Services	Vs.	Monolithic	Apps
11/1/17 40
Erlang	Philosophy Micro	Services	Archit...
Summary	:	Saga	&	Other	Design	Patterns
11/1/17 (C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 41
1. Saga	solves	the	...
11/1/17 42
1. Handling	Invariants
2. Use	Case	:	Travel	Booking	– SEC	
3. Use	Case	:	Travel	Booking	– Rollback	
4. Use	Case...
Handling	Invariants	– Monolithic	to	Micro	Services
11/1/17 43
In	a	typical	Monolithic	App	
Customer	Credit	Limit	info	and	...
Use	Case	:	Travel	Booking	– Distributed	Saga	(SEC)
11/1/17 44
Hotel	Booking
Car	Booking
Flight	Booking
Saga	
Execution	
Co...
Use	Case	:	Travel	Booking	– Rollback
11/1/17 45
Hotel	Booking
Car	Booking
Flight	Booking
Saga	
Execution	
Container
Start	...
11/1/17 46
Use	Case	:	Restaurant	– Forward	Recovery
Domain
The	example	focus	on	a	
concept	of	a	Restaurant	
which	tracks	t...
Use	Case	:	Shopping	Site	– Event	Sourcing	/	CQRS
11/1/17 47
Catalogue Shopping	Cart Order	 Payment
• Search	Products
• Add...
Use	Case	:	Movie	Booking	– Event	Sourcing	/	CQRS
11/1/17 48
Order	 Payment
• Search	Movies
• Add	Movies
• Update	Movies
Co...
Use	Case	:	Movie	Streaming	– Event	Sourcing	/	CQRS
11/1/17 49
Subscription Payment
• Search	Movies
• Add	Movies
• Update	M...
User	Case	:	Restaurant	Dining	Example	– Customer	Journey
11/1/17 50
Order	 Payment
• Add	Drinks
• Add	Food
• Update	Food
C...
Summary	– Saga	and	Event	Storming
11/1/17 51
o Scalable	Distributed	Transactions
o Local	SAGA	&	Distributed	SAGA
o Saga	Ex...
References
11/1/17 52
1. Lewis,	James,	and	Martin	Fowler.	“Microservices:	A	Definition	of	This	New	Architectural	Term”,	Ma...
References	
11/1/17 (C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 53
Domain	Driven	Design
17. Oct	27,	2012	What	I	h...
References
11/1/17 54
29. MSDN	– Microsoft	https://msdn.microsoft.com/en-us/library/dn568103.aspx
30. Martin	Fowler	:	CQRS...
References
11/1/17 (C)	COPYRIGHT	METAMAGIC	GLOBAL	INC.,	NEW	JERSEY,	USA 55
43. Greg	Young.	What	is	a	Domain	Event? http://...
References	– Micro	Services	– Videos
54. Martin	Fowler	– Micro	Services	:	https://www.youtube.com/watch?v=2yko4TbC8cI&feat...
11/1/17 57
User	Journey	:	_______________________________________________________________________
Actions Micro	Service Ev...
11/1/17 58
Thank	you
Araf	Karsh	Hamid	:	
Co-Founder	/	CTO	MetaMagic	Global	Inc.	NJ,	USA
araf.karsh@metamagic.in |	araf.kar...
Nächste SlideShare
Wird geladen in …5
×

Event Storming and Saga

2.824 Aufrufe

Veröffentlicht am

Distributed Transactions is a key concept for Micro Services based Apps and Saga Design Pattern helps out over here. However, developers struggle to shift their mindset from CRUD based design to Event Sourcing / CQRS concept. To solve this problem we are introducing the concept of Event Storming and Event Storming Process map.

Veröffentlicht in: Software
  • There are over 16,000 woodworking plans that comes with step-by-step instructions and detailed photos, Click here to take a look ●●● http://ishbv.com/tedsplans/pdf
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Get access to 16,000 woodworking plans, Download 50 FREE Plans... ●●● http://tinyurl.com/y3hc8gpw
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Want to preview some of our plans? You can get 50 Woodworking Plans and a 440-Page "The Art of Woodworking" Book... Absolutely FREE ★★★ http://tinyurl.com/yy9yh8fu
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • DOWNLOAD FULL. BOOKS INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y8nn3gmc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • There are over 16,000 woodworking plans that comes with step-by-step instructions and detailed photos, Click here to take a look ◆◆◆ http://ishbv.com/tedsplans/pdf
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

Event Storming and Saga

  1. 1. Araf Karsh Hamid : Co-Founder & CTO, MetaMagic Global Inc., NJ, USA Part 2 : Event Sourcing and Distributed Transactions for Micro Services Part 1 : Micro Services Architecture
  2. 2. 11/1/17 2 Agenda 1. Micro Services Characteristics 2. Micro Services System Design Model 3. Monolithic Vs. Micro Services Architecture 4. SOA Vs. Micro Services Architecture 5. App Scalability Based on Micro Services 6. Design Patterns Micro Services Introduction1 1. SAGA Design Pattern 2. SAGA Features 3. Local SAGA Features 4. SAGA Execution Container (SEC) 5. Let-it-Crash Design Pattern SAGA & Other Design Patterns4 1. ACID Vs. BASE 2. CAP Theorem 3. Distributed Transactions : 2 Phase Commit 4. Scalability Lessons from eBay Y Saga? Scalability Requirement3 1. Handling Invariants 2. Use Case : Travel Booking – SEC 3. Use Case : Travel Booking – Rollback 4. Use Case : Restaurant – Forward Recovery 5. Use Case : Shopping Site – ES / CQRS 6. Use Case : Movie Booking – ES / CQRS Case Studies – Examples 5 1. Event Sourcing Intro 2. Domain and Integration Events 3. Event Sourcing & CQRS Implementations 4. Mind Shift 5. Event Storming 6. Event Storming Restaurant Example 7. Event Storming Process map – Concept 8. ESP Example Event Storming2
  3. 3. Micro Services Characteristics 3 1.1 By James Lewis and Martin Fowler We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation Design for Failure Evolutionary Design
  4. 4. Micro Services System Design Model Service (Micro) Process & Tools CultureOrganization Solution (Macro) 11/1/17 4 Service: Focuses on a specific Business Capability Process & Tools: Development, Code Deployment, Maintenance and Product Management Culture: A Shared set of values, beliefs by everyone. Ubiquitous Language in DDD is an important aspect of Culture. Organization: Structure, Direction of Authority, Granularity, Composition of Teams. Solution: Coordinate all inputs and outputs of multiple services. Macro level view of the system allows the designer to focus more on desirable system behavior. 1.2 The very first step of a service design process is to design the process itself. Marc Stickdorn, author of This is Service Design Thinking
  5. 5. 11/1/175 Monolithic vs. Micro Services Example Traditional Monolithic App using Single Technology Stack Micro Services with Multiple Technology Stack Existing aPaaS vendors creates Monolithic Apps. This 3 tier model is obsolete now. Source: Gartner Market Guide for Application Platforms Nov 23, 2016 Event Stream API Gateway (Zuul Edge Server) Load Balancer (Ribbon) Circuit Breaker (Hysterix) Service Discovery (Eureka) Load Balancer (Ribbon) Circuit Breaker (Hysterix) Load Balancer (Ribbon) Circuit Breaker (Hysterix) UI Layer Web Services Business Logic Database Layer Micro Service 4 EE 7 Catalogue UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 Shopping Cart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order 1.3 UI Layer WS BL DL Database Shopping Cart Order Customer Catalogue
  6. 6. 11/1/17 6 SOA vs. Micro Services Example Traditional Monolithic App with SOA Micro Services with Multiple Technology Stack Event Stream UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 Shopping Cart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order 1.4 API Gateway Load Balancer Circuit Breaker Service Discovery Load Balancer Circuit Breaker Load Balancer Circuit Breaker UI Layer Database Shopping Cart Order Customer Catalogue Enterprise Service Bus Messaging REST / SOAP HTTP MOM JMS ODBC / JDBC Translation Web Services XML WSDL Addressing Security Registry Management Producers Shared Database Consumers3rd Party Apps Smart Pipes Lot of Business logic resides in the Pipe
  7. 7. Scale Cube and Micro Services 11/1/17 7 1. Y Axis Scaling – Functional Decomposition : Business Function as a Service 2. Z Axis Scaling – Database Partitioning : Avoid locks by Database Sharding 3. X Axis Scaling – Cloning of Individual Services for Specific Service Scalability 1.5
  8. 8. 1 November 2017 8 Design Patterns Single Component Pattern A Component shall do ONLY one thing, But do it in FULL. Single Responsibility Principle By DeMarco : Structured Analysis & System Specification (Yourdon, New York, 1979) Let-It-Crash Pattern Prefer a FULL component restart to complex internal failure handling. Candea & Fox: Crash-Only Software (USENIX HotOS IX, 2003) Popularized by Netflix Chaos Monkey. Erlang Philosophy Saga Pattern Divide long-lived distributed transactions into quick local ones with compensating actions for recovery. Pet Helland: Life Beyond Distributed Transactions CIDR 2007 1.6
  9. 9. Summary – Micro Services Intro 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 9 Benefits 1. Robust 2. Scalable 3. Testable (Local) 4. Easy to Change and Replace 5. Easy to Deploy 6. Technology Agnostic Service Oriented Architecture Micro Service Martin Fowler – Micro Services Architecture https://martinfowler.com/articles/microservices.html Dzone – SOA vs Micro Services : https://dzone.com/articles/microservices-vs-soa-2 1.7
  10. 10. 11/1/17 10 1. Event Sourcing Intro 2. Domain Events and Integration Events 3. Event Sourcing & CQRS Implementations 4. Mind Shift 5. Event Storming 6. Event Storming Restaurant Example 7. Event Storming Process map – Concept 8. ESP : Example Event Storming2 Designing Autonomous Teams and Systems
  11. 11. Event Sourcing Intro 11/1/17 11 Standard CRUD Operations – Customer Profile – Aggregate Root Profile Created Title Updated New Address added Derived Notes Removed Time T1 T2 T4T3 Event Sourcing and Derived Aggregate Root Commands 1. Create Profile 2. Update Title 3. Add Address 4. Delete Notes 2 Events 1. Profile Created Event 2. Title Updated Event 3. Address Added Event 4. Notes Deleted Event 3 Current State of the Customer Profile 4 Event store Single Source of Truth 2.1 Greg Young
  12. 12. Domain Events & Integration Events 11/1/17 12 1. Domain Events represent something happened in a specific Domain. 2. Domain Events should be used to propagate STATE changes across Multiple Aggregates within the Bounded Context. 3. The purpose of Integration Events is to propagate committed transactions and updates to additional subsystems, whether they are other microservices, Bounded Contexts or even external applications. Source: Domain Events : Design and Implementation – Microsoft Docs – May 26, 2017 Domain Data Behavior Order (Aggregate Root) Data Behavior Address (Value Object) Data Behavior OrderItem (Child) 1 n 1 1 Order Created Domain Event Micro Service Enforce consistency with other Aggregates Event Handler 1 Event Handler n Create and Publish Integration Event to Event Bus. Example: Order Placed Integration Event can be subscribed by Inventory system to update the Inventory details. Event Handler 2 2.2
  13. 13. (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA Event Sourcing and CQRS Implementation Command Handler Function 1 Function n Advantages of ES/CQRS 1. Trusted Audit Trail 2. Debugging 3. Historical State 4. Variant Schemas 5. Distribution Support 6. In-Memory Processing 7. Alternative History Kafka Sends to other Micro Services or different Read Models Event store Single Source of Truth Stores State Transitions MS 4 Order MS n Payments 11/1/17 13 2.3 Command Command Bus Checkpoint Raise Domain Event Integration Event Event Listener Can raise Function n Function 1 Listener reads Integration Events from Kafka Sends Micro Service Internals MS 1 : Analytics MS 3 : Last 3 Months Data Consumers Read DataDifferent Projections Queries MS 2 : Historical Data Event Sourced Aggregate Query Handler To Build Aggregate Root from Event Stream Aggregate Factory use Query Aggregate (ID) Service / Request Handler
  14. 14. Mind Shift : From Object Modeling to Process Modeling 11/1/17 14 2.4 Developers with Strong Object Modeling experience will have trouble making Events a first class citizen. • How do I start Event Sourcing? • Where do I Start on Event Sourcing / CQRS? The Key is: 1. App User’s Journey 2. Business Process 3. Ubiquitous Language – DDD 4. Capability Centric Design 5. Outcome Oriented The Best tool to define your process and its tasks. How do you define your End User’s Journey & Business Process? • Think It • Build It • Run IT
  15. 15. App User’s Journey & Bounded Context (DDD) 11/1/17 15 2.4 1 An App User’s Journey can run across multiple Bounded Context / Micro Services. User Journey X Bounded Context Bounded Context Bounded Context User Journey Y Bounded Context Bounded Context Bounded Context Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Understanding Bounded Context (DDD) of a Restaurant App Dinning Context Kitchen Context Menu Context Source: Domain-Driven Design Reference by Eric Evans
  16. 16. Business Solution & Business Process 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 16 2.4 2 q Business Solution focuses the entire Journey of the User which can run across multiple Micro Services. q Business Solution comprises a set of Business Processes. q Business Process focuses on a specific Micro Service and its functionality. Business Solution: Customer Dining Experience Order PaymentFood Menu KitchenDining Browse Menu Order Dinner Dinner Served Get Bill Make Payment
  17. 17. Ubiquitous Language : Understanding Requirement Analysis using DDD 1 November 2017 17 Ubiquitous Language Vocabulary shared by all involved parties Used in all forms of spoken / written communication Ubiquitous Language using BDD As an insurance Broker I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys insurance ABC for $1000 USD Then He becomes a Gold Customer BDD – Behavior Driven Development 2.4 3 Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Food Item : Eg. Food Item (Navrathnakurma) can have different meaning or properties depends on the context. • In the Menu Context it’s a Veg Dish. • In the Kitchen Context it’s is recipe. • And in the Dining Context it will have more info related to user feed back etc.
  18. 18. Capability Centric Design 11/1/17 18 2.4 4 Front-End Back-End Database Business Capability 1 Front-End Back-End Database Business Capability 2 Front-End Back-End Database Business Capability 3 Vertically sliced Product Team Front-End-Team Back-End-Team Database-Team In a typical Monolithic way the team is divided based on technology / skill set rather than business functions. This leads to not only bottlenecks but also lack of understanding of the Business Domain. Business Centric Development • Focus on Business Capabilities • Entire team is aligned towards Business Capability. • From Specs to Operations – The team handles the entire spectrum of Software development. • Every vertical will have it’s own Code Pipeline
  19. 19. 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 19
  20. 20. 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 20 Process • Define your Business Processes. Eg. Various aspects of Order Processing in an E-Commerce Site, Movie Ticket Booking, Patient visit in Hospital. 1 Commands • Define the Commands (End-User interaction with your App) to execute the Process. Eg. Add Item to Cart is a Command. 2 Event Sourced Aggregate • Current state of the Aggregate is always derived from the Event Store. Eg. Shopping Cart, Order etc. This will be part of the Rich Domain Model (Bounded Context) of the Micro Service.4 Projections • Projections focuses on the View perspective of the Application. As the Read & Write are different Models, you can have different Projections based on your View perspective. 5 Write Data Read Data Events • Commands generates the Events to be stored in Event Store. Eg. Item Added Event (in the Shopping Cart). 3 Event Storming – Concept 2.5
  21. 21. Event Storming : Restaurant Dining Example – Customer Journey 11/1/17 21 Order Payment • Add Drinks • Add Food • Update Food Commands • Open Table • Add Juice • Add Soda • Add Appetizer 1 • Add Appetizer 2 • Serve Drinks • Prepare Food • Serve Food Events • Drinks Added • Food Added • Food Updated • Food Discontinued • Table Opened • Juice Added • Soda Added • Appetizer 1 Added • Appetizer 2 Added • Juice Served • Soda Served • Appetizer Served • Food Prepared • Food Served • Prepare Bill • Process Payment • Bill Prepared • Payment Processed • Payment Approved • Payment Declined • Cash Paid When people arrive at the Restaurant and take a table, a Table is opened. They may then order drinks and food. Drinks are served immediately by the table staff, however food must be cooked by a chef. Once the chef prepared the food it can then be served. Table is closed when the bill is prepared. Microservices • Dinning Order • Billable Order Customer Journey thru Dinning Processes Processes Food Menu KitchenDining • Remove Soda • Add Food 1 • Add Food 2 • Place Order • Close Table • Remove Soda • Food 1 Added • Food 2 Added • Order Placed • Table Closed ES Aggregate 3 2 4 1 The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 2.6
  22. 22. Event Storming Process map – Concept 11/1/17 22 1. Define your User Journey.User Journey 2.7 DE IE Domain Events Integration Events 7. Events Event(s)Command Micro Service 3. Command & Event(s) BridgeC Commands execute the tasks required to complete the Business Process. Aggregate Root 4. Event Sourced Aggregate Event Sourced Aggregate is derived from a Collection of Events & Factory builds these Aggregate Root Query Name Micro Service 5. Handling Queries in the Process Q Some commands are issued after the User interaction with Query Result Event Listener Micro Service 6. Listener listens for Domain & Integration Events L Listeners plays the key role in Inter Micro Services communications Aggregate Factory 8. Factory Factory Builds the Event Sourced Aggregate Root based on the Business Rules defined. 2. ESP is drawn inside 5 Vertical Swim Lanes. 1. Process Name & User interacting with the App 2. Actions by the user 3. Micro Service(s) involved 4. Events raised due to the command 5. Event Sourced Aggregate Root & Aggregate Factory
  23. 23. Table OpenedOpen TableC DE 11/1/17 23 ESP : Customer’s Dinning Journey : 1–of–3 Actions Micro Service Events ES Aggregate 2.8 2 3 4 List Food Menu Food Menu Q Juice AddedAdd JuiceC DE Soda AddedAdd SodaC DE Appetizer 1 AddedAdd Appetizer 1C DE Appetizer 2 AddedAdd Appetizer 2C DE Soda RemovedRemove SodaC DE Food 1 AddedAdd Food 1C DE Order PlacedPlace OrderC IE 1. Dinning Order (This will have all the Events associated with the Customers Dining experience.) 2. Order (Will Contain only the actual order) Dining The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. Factory Builds the Aggregates Process 1 Browse Menu Process 2 Order Food Aggregate Root is always derived from the Event Store at the time of the Query.
  24. 24. 11/1/17 24 ESP : Customer’s Dinning Journey : 2–of–3 Actions Micro Service Events ES Aggregate 2.8 2 3 4 Table ClosedClose TableC DE Order PlacedOrder Listener DEL Juice ServedServe JuiceC DE IE Soda ServedServe SodaC DE IE Appetizer 1 ServedServe Appetizer 1C DE IE Juice ServedServing Listener DEL Soda ServedServing Listener DEL Appetizer 1 ServedServing Listener DEL Food 1 ServedServing Listener DEL Dining Food PreparedPrepared FoodC DE Food ServedServe FoodC DE IE Kitchen 1. Order Served (This Aggregate Root will help track the Re- Ordering the food Raw materials) 3. Billable Order (This will contain only the Served Item) Aggregate Root is always derived from the Event Store at the time of the Query. Factory Builds the Aggregates Process 4 Serve Food Process 3 Prepare Food
  25. 25. Payment StatusProcess PaymentC IE 11/1/17 25 ESP : Customer’s Dinning Journey : 3–of–3 Actions Micro Service Events ES Aggregate 2.8 2 3 4 Payment ApprovedPayment Listener DEL Bill PreparedPrepare BillC DE Payment ProcessedProcess PaymentC DE IEOrder 1. Bill (This will contain only the Served Item) Payment 2. Bill Payment (This will contain the Payment details) Aggregate Root is always derived from the Event Store at the time of the Query. The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. Factory Builds the Aggregates Process 5 Make Payment
  26. 26. Summary – ESP : Event Sourcing Process map 11/1/17 26 Process1 Commands2 Projections5 ES Aggregate4 Events3 User Journey X Bounded Context Bounded Context Bounded Context Front-End Back-End Database Business Capability 1 Front-End Back-End Database Business Capability 2 Front-End Back-End Database Business Capability 3 Vertically sliced Product Team Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code 2.9
  27. 27. 11/1/17 27 1. ACID Vs. BASE 2. CAP Theorem 3. Distributed Transactions : 2 Phase Commit 4. Scalability Lessons from eBay Scalability Requirement in Cloud3 Y SAGA ?
  28. 28. ACID Vs. BASE ACID Atomic ◦ All operations in a transaction succeed or every operation is rolled back. Consistent ◦ On the completion of a transaction, the database is structurally sound. Isolated ◦ Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially. Durable ◦ The results of applying a transaction are permanent, even in the presence of failures. BASE Basic Availability ◦ The database appears to work most of the time. Soft-state ◦ Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time. Eventual consistency ◦ Stores exhibit consistency at some later point (e.g., lazily at read time). 11/1/17 28 Source: https://neo4j.com/blog/acid-vs-base-consistency-models-explained/ 3.1
  29. 29. CAP Theorem by Eric Allen Brewer 1 November 2017 29 Pick Any 2!! Say NO to 2 Phase Commit J Source: https://en.wikipedia.org/wiki/CAP_theorem | http://en.wikipedia.org/wiki/Eric_Brewer_(scientist) CAP 12 years later: How the “Rules have changed” “In a network subject to communication failures, it is impossible for any web service to implement an atomic read / write shared memory that guarantees a response to every request.” Partition Tolerance The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes. Consistency Every read receives the most recent write or an error. Availability Every request receives a (non-error) response – without guarantee that it contains the most recent write. 3.2
  30. 30. Distributed Transactions : 2 Phase Commit 2 PC or not 2 PC, Wherefore Art Thou XA? 1 November 2017 30 How does 2PC impact scalability? • Transactions are committed in two phases. • This involves communicating with every database (XA Resources) involved to determine if the transaction will commit in the first phase. • During the second phase each database is asked to complete the commit. • While all of this coordination is going on, locks in all of the data sources are being held. • The longer duration locks create the risk of higher contention. • Additionally, the two phases require more database processing time than a single phase commit. • The result is lower overall TPS in the system. Transaction Manager XA Resources Request to Prepare Commit Prepared Prepare Phase Commit PhaseDone Source : Pat Helland (Amazon) : Life Beyond Distributed Transactions Distributed Computing : http://dancres.github.io/Pages/ Solution : Resilient System • Event Based • Design for failure • Asynchronous Recovery • Make all operations idempotent. • Each DB operation is a 1 PC 3.3
  31. 31. Scalability Best Practices : Lessons from Best Practices Highlights #1 Partition By Function • Decouple the Unrelated Functionalities. • Selling functionality is served by one set of applications, bidding by another, search by yet another. • 16,000 App Servers in 220 different pools • 1000 logical databases, 400 physical hosts #2 Split Horizontally • Break the workload into manageable units. • eBay’s interactions are stateless by design • All App Servers are treated equal and none retains any transactional state • Data Partitioning based on specific requirements #3 Avoid Distributed Transactions • 2 Phase Commit is a pessimistic approach comes with a big COST • CAP Theorem (Consistency, Availability, Partition Tolerance). Apply any two at any point in time. • @ eBay No Distributed Transactions of any kind and NO 2 Phase Commit. #4 Decouple Functions Asynchronously • If Component A calls component B synchronously, then they are tightly coupled. For such systems to scale A you need to scale B also. • If Asynchronous A can move forward irrespective of the state of B • SEDA (Staged Event Driven Architecture) #5 Move Processing to Asynchronous Flow • Move as much processing towards Asynchronous side • Anything that can wait should wait #6 Virtualize at All Levels • Virtualize everything. eBay created their on O/R layer for abstraction #7 Cache Appropriately • Cache Slow changing, read-mostly data, meta data, configuration and static data. 1 November 2017 31 Source: http://www.infoq.com/articles/ebay-scalability-best-practices 3.4
  32. 32. Summary : Scalability Requirement in Cloud 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 32 1. Availability and Partition Tolerance is more important than immediate Consistency. 2. Eventual Consistency is more suitable in a highly scalable Cloud Environment 3. Two Phase Commit has its limitations from Scalability perspective and it’s a Single Point of Failure. 4. Scalability examples from eBay, Amazon, Netflix, Uber, Airbnb etc. 3.5
  33. 33. 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 33 1. SAGA Introduction 2. SAGA Features 3. Local SAGA Features 4. SAGA Execution Container (SEC) 5. Let-it-Crash Design Pattern 6. Domain Events & Integration Events SAGA & Other Design Patterns4
  34. 34. SAGA Design Pattern Introduction 11/1/17 34 Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying the termination of shorter and more common transactions. Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA T1 T2 Tn Local Transactions C1 C2 Cn-1 Compensating Transaction Divide long–lived, distributed transactions into quick local ones with compensating actions for recovery. Travel : Flight Ticket & Hotel Booking Example BASE (Basic Availability, Soft State, Eventual Consistency) Room ReservedT1 Room PaymentT2 Seat ReservedT3 Ticket PaymentT4 Cancelled Room Reservation C1 Cancelled Room Payment C2 Cancelled Ticket Reservation C3 4.1
  35. 35. SAGA Features 11/1/17 35 1. Backward Recovery (Rollback) T1 T2 T3 T4 C3 C2 C1 Order Processing, Banking Transactions, Ticket Booking Examples Updating individual scores in a Team Game. 2. Forward Recovery with Save Points T1 (sp) T2 (sp) T3 (sp) • To recover from Hardware Failures, SAGA needs to be persistent. • Save Points are available for both Forward and Backward Recovery. Type 4.2 Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA
  36. 36. Local SAGA Features 11/1/17 36 1. Part of the Micro Services 2. Local Transactions and Compensation Transactions 3. SAGA State is persisted 4. All the Local transactions are based on Single Phase Commit (1 PC) 5. Developers need to ensure that appropriate compensating transactions are Raised in the event of a failure. API Examples @StartSaga(name=“HotelBooking”) public void reserveRoom(…) { } @EndSaga(name=“HotelBooking”) public void payForTickets(…) { } @AbortSaga(name=“HotelBooking”) public void cancelBooking(…) { } @CompensationTx() public void cancelReservation(…) { } 4.3
  37. 37. SAGA Execution Container 11/1/17 37 1. SEC is a separate Process 2. Stateless in nature and Saga state is stored in a messaging system (Kafka is a Good choice). 3. SEC process failure MUST not affect Saga Execution as the restart of the SEC must start from where the Saga left. 4. SEC – No Single Point of Failure (Master Slave Model). 5. Distributed SAGA Rules are defined using a DSL. 4.4
  38. 38. Let-it-Crash Design Pattern – Erlang Philosophy 11/1/17 38 • The Erlang view of the world is that everything is a process and that processes can interact only by exchanging messages. • A typical Erlang program might have hundreds, thousands, or even millions of processes. • Letting processes crash is central to Erlang. It’s the equivalent of unplugging your router and plugging it back in – as long as you can get back to a known state, this turns out to be a very good strategy. • To make that happen, you build supervision trees. • A supervisor will decide how to deal with a crashed process. It will restart the process, or possibly kill some other processes, or crash and let someone else deal with it. • Two models of concurrency: Shared State Concurrency, & Message Passing Concurrency. The programming world went one way (toward shared state). The Erlang community went the other way. • All languages such as C, Java, C++, and so on, have the notion that there is this stuff called state and that we can change it. The moment you share something you need to bring Mutex a Locking Mechanism. • Erlang has no mutable data structures (that’s not quite true, but it’s true enough). No mutable data structures = No locks. No mutable data structures = Easy to parallelize. 4.5
  39. 39. Let-it-Crash Design Pattern 11/1/17 39 1. The idea of Messages as the first class citizens of a system, has been rediscovered by the Event Sourcing / CQRS community, along with a strong focus on domain models. 2. Event Sourced Aggregates are a way to Model the Processes and NOT things. 3. Each component MUST tolerate a crash and restart at any point in time. 4. All interaction between the components must tolerate that peers can crash. This mean ubiquitous use of timeouts and Circuit Breaker. 5. Each component must be strongly encapsulated so that failures are fully contained and cannot spread. 6. All requests sent to a component MUST be self describing as is practical so that processing can resume with a little recovery cost as possible after a restart. 4.5
  40. 40. Let-it-Crash : Comparison Erlang Vs. Micro Services Vs. Monolithic Apps 11/1/17 40 Erlang Philosophy Micro Services Architecture Monolithic Apps (Java, C++, C#, Node JS ...) 1 Perspective Everything is a Process Event Sourced Aggregates are a way to model the Process and NOT things. Things (defined as Objects) and Behaviors 2 Crash Recovery Supervisor will decide how to handle the crashed process A combination of IaaS (AWS / Azure …), Load Balancer (Netflix Ribbon) and Service Discovery (Netflix Eureka) will handle the crashed Micro Service along with Circuit Breaker pattern to handle fallback mechanism. Not available. Most of the monolithic Apps are Stateful and Crash Recovery needs to be handled manually and all languages other than Erlang focuses on defensive programming. 3 Concurrency Message Passing Concurrency Domain Events for state changes within a Bounded Context & Integration Events for external Systems. Mostly Shared State Concurrency 4 State Stateless : Mostly Immutable Structures Immutability is handled thru Event Sourcing along with Domain Events and Integration Events. Predominantly Stateful with Mutable structures and Mutex as a Locking Mechanism 5 Citizen Messages Messages are 1st class citizen by Event Sourcing / CQRS pattern with a strong focus on Domain Models Mutable Objects and Strong focus on Domain Models and synchronous communication. 4.5
  41. 41. Summary : Saga & Other Design Patterns 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 41 1. Saga solves the distributed Transaction problems 2 Phase commit had and with its asynchronous and not having a single point of failure makes it a perfect candidate for cloud computing. 2. Developer Complexity is increased with Saga Pattern as Developers needs to focus on Rollbacks and Roll forwards with Compensating transactions. 3. Let-it-Crash is not just a programming pattern like Singleton, Factory or Observer etc. It’s a pattern that runs across the programming paradigm and your infrastructure paradigm. 4.6
  42. 42. 11/1/17 42 1. Handling Invariants 2. Use Case : Travel Booking – SEC 3. Use Case : Travel Booking – Rollback 4. Use Case : Restaurant – Forward Recovery 5. Use Case : Shopping Site – Event Sourcing / CQRS 6. Use Case : Movie Booking – Event Sourcing / CQRS 7. Use Case : Restaurant Dinning – Event Sourcing / CQRS 8. Summary 9. References Case Studies – Examples 5
  43. 43. Handling Invariants – Monolithic to Micro Services 11/1/17 43 In a typical Monolithic App Customer Credit Limit info and the order processing is part of the same App. Following is a typical pseudo code. 5.1 Order CreatedT1 Order Micro Service Credit ReservedT2 Customer Micro Service In Micro Services world with Event Sourcing, it’s a distributed environment. The order is cancelled if the Credit is NOT available. If the Payment Processing is failed then the Credit Reserved is cancelled. Payment Micro ServicePayment ProcessedT3 Order Cancelled C1 Credit Cancelled due to payment failureC2 Begin Transaction If Order Value <= Available Credit Process Order Process Payments End Transaction Monolithic 2 Phase Commit https://en.wikipedia.org/wiki/Invariant_(computer_science)
  44. 44. Use Case : Travel Booking – Distributed Saga (SEC) 11/1/17 44 Hotel Booking Car Booking Flight Booking Saga Execution Container Start Saga {Booking Request} Payment End Saga Start Saga Start Hotel End Hotel Start Car End Car Start Flight End Flight Start Payment End Payment Saga Log End Saga {Booking Confirmed} SEC knows the structure of the distributed Saga and for each of the Request Which Service needs to be called and what kind of Recovery mechanism it needs to be followed. SEC can parallelize the calls to multiple services to improve the performance. The Rollback or Roll forward will be dependent on the business case. 5.2 Source: Distributed Sagas By Catitie McCaffrey, June 6, 2017
  45. 45. Use Case : Travel Booking – Rollback 11/1/17 45 Hotel Booking Car Booking Flight Booking Saga Execution Container Start Saga {Booking Request} Payment Start Comp Saga End Comp Saga Start Hotel End Hotel Start Car Abort Car Cancel Hotel Cancel Flight Saga Log End Saga {Booking Cancelled} Kafka is a good choice to implement the SEC log. SEC is completely STATELESS in nature. Master Slave model can be implemented to avoid the Single Point of Failure. 5.3 Source: Distributed Sagas By Catitie McCaffrey, June 6, 2017
  46. 46. 11/1/17 46 Use Case : Restaurant – Forward Recovery Domain The example focus on a concept of a Restaurant which tracks the visit of an individual or group to the Restaurant. When people arrive at the Restaurant and take a table, a table is opened. They may then order drinks and food. Drinks are served immediately by the table staff, however food must be cooked by a chef. Once the chef prepared the food it can then be served. PaymentBillingDining Source: http://cqrs.nu/tutorial/cs/01-design Soda Cancelled Table Opened Juice Ordered Soda Ordered Appetizer Ordered Soup Ordered Food Ordered Juice Served Food Prepared Food Served Appetizer Served Table Closed Aggregate Root : Dinning Order Billed OrderT1 Payment CCT2 Payment CashT3 T1 (sp) T2 (sp) T3 (sp) Event Stream Aggregate Root : Food Bill Transaction doesn't rollback if one payment method is failed. It moves forward to the NEXT one. sp Network ErrorC1 sp 5.4
  47. 47. Use Case : Shopping Site – Event Sourcing / CQRS 11/1/17 47 Catalogue Shopping Cart Order Payment • Search Products • Add Products • Update Products Commands • Add to Cart • Remove Item • Update Quantity Customer • Process Order • Select Address • Select Delivery Mode Events • Product Added • Product Updated • Product Discontinued • Item Added • Item Removed / Discontinued • Item Updated • Order Initiated • Address Selected • Delivery Mode Selected • Order Created • Proceed for Payment • Confirm Order for Payment • Cancel Order • Payment Initiated • Order Cancelled • Order Confirmed • OTP Send • Payment Approved • Payment Declined Commands are End-User interaction with the App and based on the commands (Actions) Events are created. These Events includes both Domain Events and Integration Events. Event Sourced Aggregates will be derived using Domain Events. Each Micro Service will have its own separate Database. Depends on the scalability requirement each of the Micro Service can be scaled separately. For Example. Catalogue can be on a 50 node cluster compared to Customer Micro Service. Microservices • Customer • Shop.. Cart • Order 5.5 Customer Journey thru Shopping Process The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 3 2 ES Aggregate 4
  48. 48. Use Case : Movie Booking – Event Sourcing / CQRS 11/1/17 48 Order Payment • Search Movies • Add Movies • Update Movies Commands • Select Movie • Select Theatre / Show • Select Tickets • Process Order • Select Food • Food Removed • Skip Food • Process Order Events • Movie Added • Movie Updated • Movie Discontinued • Movie Added • Theatre / Show Added • Tickets Added • Order Initiated • Popcorn Added • Drinks Added • Popcorn Removed • Order Finalized • Proceed for Payment • Confirm Order for Payment • Cancel Order • Payment Initiated • Order Cancelled • Order Confirmed • OTP Send • Payment Approved • Payment Declined Movies Theatres Food Microservices Commands are End-User interaction with the App and based on the commands (Actions) Events are created. These Events includes both Domain Events and Integration Events. Event Sourced Aggregates will be derived using Domain Events. Each Micro Service will have its own separate Database. Depends on the scalability requirement each of the Micro Service can be scaled separately. For Example. Theatre can be on a 50 node cluster compared to Food Micro Service. • Theatre • Show • Order 1 5.6 Customer Journey thru booking Movie Ticket The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 3 2 ES Aggregate 4
  49. 49. Use Case : Movie Streaming – Event Sourcing / CQRS 11/1/17 49 Subscription Payment • Search Movies • Add Movies • Update Movies Commands • Request Streaming • Start Movie Streaming • Pause Movie Streaming • Validate Streaming License • Validate Download License Events • Movie Added • Movie Updated • Movie Discontinued • Streaming Requested • Streaming Started • Streaming Paused • Streaming Done • Streaming Request Accepted • Streaming Request Denied • Subscribe Monthly • Subscribe Annually • Monthly Subscription Added • Yearly Subscription Added • Payment Approved • Payment Declined Discovery Microservices Commands are End-User interaction with the App and based on the commands (Actions) Events are created. These Events includes both Domain Events and Integration Events. Event Sourced Aggregates will be derived using Domain Events. Each Micro Service will have its own separate Database. Depends on the scalability requirement each of the Micro Service can be scaled separately. For Example. Theatre can be on a 50 node cluster compared to Food Micro Service. • Stream List • Favorite List 2 5.6 Customer Journey thru Streaming Movie / TV Show The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. LicenseStreaming 3 2 ES Aggregate 4
  50. 50. User Case : Restaurant Dining Example – Customer Journey 11/1/17 50 Order Payment • Add Drinks • Add Food • Update Food Commands • Open Table • Add Juice • Add Soda • Add Appetizer 1 • Add Appetizer 2 • Serve Drinks • Prepare Food • Serve Food Events • Drinks Added • Food Added • Food Updated • Food Discontinued • Table Opened • Juice Added • Soda Added • Appetizer 1 Added • Appetizer 2 Added • Juice Served • Soda Served • Appetizer Served • Food Prepared • Food Served • Prepare Bill • Process Payment • Bill Prepared • Payment Processed • Payment Approved • Payment Declined • Cash Paid When people arrive at the Restaurant and take a table, a Table is opened. They may then order drinks and food. Drinks are served immediately by the table staff, however food must be cooked by a chef. Once the chef prepared the food it can then be served. Table is closed when the bill is prepared. Microservices • Dinning Order • Billable Order Customer Journey thru Dinning Processes Processes Food Menu KitchenDining • Remove Soda • Add Food 1 • Add Food 2 • Place Order • Close Table • Remove Soda • Food 1 Added • Food 2 Added • Order Placed • Table Closed ES Aggregate 3 2 4 1 The purpose of this example is to demonstrate the concept of ES / CQRS thru Event Storming principles. 5.7
  51. 51. Summary – Saga and Event Storming 11/1/17 51 o Scalable Distributed Transactions o Local SAGA & Distributed SAGA o Saga Execution Container o Domain and Integration Events o Let-it-Crash Design Pattern and Erlang Philosophy 5.8 Process1 Commands2 Projections5 ES Aggregate4 Events3 ESP Diagrams
  52. 52. References 11/1/17 52 1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Ketan Gote, May 22, 2017 – Zuul Edge Server 10. Ketan Gote, May 22, 2017 – Ribbon, Hysterix using Spring Feign 11. Ketan Gote, May 22, 2017 – Eureka Server with Spring Cloud 12. Ketan Gote, May 20, 2017 – Apache Kafka, A Distributed Streaming Platform 13. Araf Karsh Hamid, August 7, 2016 – Functional Reactive Programming 14. Araf Karsh Hamid, July 30, 2016 – Enterprise Software Architectures 15. Araf Karsh Hamid, April 28, 2015 – Docker and Linux Containers 16. Araf Karsh Hamid, Oct 6, 2017 – Micro Services Architecture 1 5.9
  53. 53. References 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 53 Domain Driven Design 17. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans 18. Mar 19, 2013 Domain Driven Design By Eric Evans 19. May 16, 2015 Microsoft Ignite: Domain Driven Design for the Database Driven Mind 20. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 21. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 22. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 23. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 24. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune Event Sourcing and CQRS 25. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 26. Mar 22, 2016 Spring Developer – Building Micro Services with Event Sourcing and CQRS 27. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 28. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes 2 5.9
  54. 54. References 11/1/17 54 29. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 30. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 31. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ 32. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs 33. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 34. CQS : http://en.wikipedia.org/wiki/Command–query_separation 35. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 36. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 37. CAP 12 years how the rules have changed 38. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 39. Pat Helland (Amazon) : Life beyond distributed transactions 40. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 41. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem 42. Rx Observable : https://dzone.com/articles/using-rx-java-observable 3 5.9
  55. 55. References 11/1/17 (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA 55 43. Greg Young. What is a Domain Event? http://codebetter.com/gregyoung/2010/04/11/what-is-a-domain-event/ 44. Jan Stenberg. Domain Events and Eventual Consistency https://www.infoq.com/news/2015/09/domain-events- consistency 45. Jimmy Bogard. A better domain events pattern https://lostechies.com/jimmybogard/2014/05/13/a-better- domain-events-pattern/ 46. Vaughn Vernon. Effective Aggregate Design Part II: Making Aggregates Work Together http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf 47. Jimmy Bogard. Strengthening your domain: Domain Events*https://lostechies.com/jimmybogard/2010/04/08/strengthening-your-domain-domain-events/ * 48. Tony Truong. Domain Events Pattern Example http://www.tonytruong.net/domain-events-pattern-example/ 49. Udi Dahan. How to create fully encapsulated Domain Models http://udidahan.com/2008/02/29/how-to-create- fully-encapsulated-domain-models/ 50. Udi Dahan. Domain Events – Take 2 http://udidahan.com/2008/08/25/domain-events-take-2/ 51. Udi Dahan. Domain Events – Salvation http://udidahan.com/2009/06/14/domain-events-salvation/ 52. Jan Kronquist. Don't publish Domain Events, return them! https://blog.jayway.com/2013/06/20/dont-publish- domain-events-return-them/ 53. Cesar de la Torre. Domain Events vs. Integration Events in DDD and microservices architectures https://blogs.msdn.microsoft.com/cesardelatorre/2017/02/07/domain-events-vs-integration-events-in-domain- driven-design-and-microservices-architectures/ 4 5.9
  56. 56. References – Micro Services – Videos 54. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 55. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 56. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 57. GOTO 2015 – Challenges Implementing Micro Services By Fred George 58. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 59. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 60. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 61. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 62. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 63. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 64. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 65. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 66. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 67. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 68. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 69. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 70. GOTO 2017 – Microservices without Servers. By Glynn Bird. 11/1/17 56 5 5.9
  57. 57. 11/1/17 57 User Journey : _______________________________________________________________________ Actions Micro Service Events ES Aggregate2 3 4 Process 1 Name Process 2 Name Process 3 Name 5.10
  58. 58. 11/1/17 58 Thank you Araf Karsh Hamid : Co-Founder / CTO MetaMagic Global Inc. NJ, USA araf.karsh@metamagic.in | araf.karsh@gmail.com USA: +1 (973) 969-2921 India: +91.999.545.8627 Skype / LinkedIn / Twitter / Slideshare : arafkarsh http://www.slideshare.net/arafkarsh https://www.linkedin.com/in/arafkarsh/ A Micro Service will have its own Code Pipeline for build and deployment functionalities and it’s scope will be defined by the Bounded Context focusing on the Business Capabilities and the interoperability between Micro Services will be achieved using (asynchronous) message based communication.

×