Building Cloud-Native App Series - Part 1 of 15
Microservices Architecture Series
Design Thinking,
Lean Startup,
Agile (Kanban, Scrum),
Epics, User Stories,
BDD - Acceptance Criteria
Domain-Driven Design
@arafkarsh arafkarsh
8 Years
Network &
Security
6+ Years
Microservices
Blockchain
8 Years
Cloud
Computing
8 Years
Distributed
Computing
Architecting
& Building Apps
a tech presentorial
Combination of
presentation & tutorial
ARAF KARSH HAMID
Co-Founder / CTO
MetaMagic Global Inc., NJ, USA
@arafkarsh
arafkarsh
1
Microservice
Architecture Series
Design Thinking / Lean Startup
Agile (Scrum/Kanban) / User Stories
Architecture Styles
Domain Driven Design
RESTful / Open API 3.0
Part 1 of 15
To Build Cloud Native Apps
Using Composable Enterprise Architecture
@arafkarsh arafkarsh 2
Slides are color coded based on the topic colors.
Design Thinking /
Lean / Agile
Capability Centric Design
User Stories
1
Architecture Styles
and Patterns
2
Domain Driven
Design
3
RESTful &
Open API 3.0
Guidelines
4
@arafkarsh arafkarsh
Agile
Scrum (4-6 Weeks)
Developer Journey
Monolithic
Domain Driven Design
Event Sourcing and CQRS
Waterfall
Optional
Design
Patterns
Continuous Integration (CI)
6/12 Months
Enterprise Service Bus
Relational Database [SQL] / NoSQL
Development QA / QC Ops
3
Microservices
Domain Driven Design
Event Sourcing and CQRS
Scrum / Kanban (1-5 Days)
Mandatory
Design
Patterns
Infrastructure Design Patterns
CI
DevOps
Event Streaming / Replicated Logs
SQL NoSQL
CD
Container Orchestrator Service Mesh
@arafkarsh arafkarsh 4
100s Microservices
1,000s Releases / Day
10,000s Virtual Machines
100K+ User actions / Second
81 M Customers Globally
1 B Time series Metrics
10 B Hours of video streaming
every quarter
Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM
10s OPs Engineers
0 NOC
0 Data Centers
So what do NetFlix think about DevOps?
No DevOps
Don’t do lot of Process / Procedures
Freedom for Developers & be Accountable
Trust people you Hire
No Controls / Silos / Walls / Fences
Ownership – You Build it, You Run it.
@arafkarsh arafkarsh 5
50M Paid Subscribers
100M Active Users
60 Countries
Cross Functional Team
Full, End to End ownership of features
Autonomous
1000+ Microservices
Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf
1000+ Tech Employees
120+ Teams
@arafkarsh arafkarsh
Three Mindsets of Product Development
6
Design
Thinking Lean Agile
Explore the
Problem
Build the
right things
Build the
things right
0
@arafkarsh arafkarsh
Product Mindset
7
Identify the
Problem
Define the
Value
Validate the
Outcome
Discovery is the new
knowing
Until proven by market response,
outcomes are merely
conjectures.
The worth of a product is
determined by the amount a
customer is willing to spend
on it.
Source: https://www.clearlyagile.com/agile-blog/3-steps-to-grow-our-product-mindset
Examples
1. Google Gmail (Search, UI, Storage)
2. Apple iPod ($0.99 Song, UI, Storage)
@arafkarsh arafkarsh
Discovery Vs. Delivery
8
Increasing
level of
Evidence of
Value
Increasing level of Effort
Developing a product without finding evidence of
its value is a waste of time and resources.
Observe &
Interact Protypes
Explainer
Videos
Landing
Pages
Concierge
MVP
Wizard
of OZ
MVP
Beta
Release
Product
Launch
Design
Thinking Lean Agile
Explore the
Problem
Build the
right things
Build the
things right
If You are NOT doing these
Then this is waste
Single
Customer
Example
Amazon had
Human Book
Reviewers
before they
automated it
Example
Dropbox: Customer
interests went up
from 5K to 70K
@arafkarsh arafkarsh
Design Thinking
9
Empathize
1
Define
2
Ideate
3
Prototype
4
• Who the user is (User Profile / Persona)?
• What their needs are? What do they do?
Test
5
Is a Philosophy and a set of tools to solve the problem Creatively.
Human Centered
Design
Don’t worry about Technology
• From Step 1: Observations, Discoveries, Challenges >> Insights
• Defines the Problem
• Ideas, Solutions
• Potential Matches
• Select and Turn the Ideas into
• Testable Prototypes
• Test with Real users
• Gather the Feedback, Observations, New Insights
@arafkarsh arafkarsh
Design Thinking
Business Thinking Design Thinking
Market Analysis What might be
Definitive Iterative
Focus Groups Observation
Spreadsheets Stories / Scenarios
Individual Responsibility Collaboration
Permanent Jobs Temporary Projects
10
Tom Klinkowstein – Professor of Design & New Media, New York
@arafkarsh arafkarsh 11
Lean Startup
Build
Measure
Learn
Design Thinking
1 Feedback
Loop
2 Experiment Observe
Don’t Ask
1
2
3
• Movie Streaming (NetFlix), Music Streaming (Spotify),
• Drive In Takeaways (McDonalds), Build your furniture (IKEA)
3 Minimum Viable Product (MVP)
Eric Ries
Video
MVP
Concierge
MVP
Wizard of
OZ
• DropBox Video
Demo
• Steve Jobs Next
OS
• Single Customer
• Adapt the features
to other customers
later
• Amazon had
Human Book
Reviewers before
they automated it.
@arafkarsh arafkarsh
Design
Thinking
12
Empathize
Define
Ideate
Prototype
Test
Ideate
Build
Product
Measure
Data
Learn
Lean
Startup
Design Thinking / Lean Startup
@arafkarsh arafkarsh
Agile Manifesto (Values)
13
INDIVIDUALS AND
INTERACTIONS
OVER PROCESSESS
AND TOOLS
WORKING SOFTWARE
COMPREHENSIVE
DOCUMENTATION
OVER
CUSTOMER
COLLABORATION
OVER CONTRACT
NEGOTIATION
RESPONDING
TO CHANGE
OVER FOLLOWING
A PLAN
Source: Agile Manifesto - https://www.scrumalliance.org/resources/agile-manifesto
@arafkarsh arafkarsh
Three Mindsets of Product Development
14
Design
Thinking
Lean Agile
Source: Jonny Schneider, Thought Works
Explore the
Problem
Build the
right things
Build the
things right
Hypothesis
Validation
New Business Requirements
Product Evolutions
Agile
MVP
@arafkarsh arafkarsh
3 Mindset of Product Development
15
Increasing
level of
Evidence of
Value
Increasing level of Effort
Developing a product without finding evidence
of its value is a waste of time and resources.
Observe &
Interact Protypes
Explainer
Videos
Landing
Pages
Concierge
MVP
Wizard
of OZ
MVP
Beta
Release
Product
Launch
Design
Thinking Lean Agile
Explore the
Problem
Build the
right things
Build the
things right
If You are NOT doing these
Then this is waste
Single
Customer
Example
Amazon had
Human Book
Reviewers
before they
automated it
Example
Dropbox: Customer
interests went up
from 5K to 70K
The Problem The Solution
@arafkarsh arafkarsh 16
@arafkarsh arafkarsh
Design Thinking / Lean / Agile
17
Principles Foundation
1 Customer Value / Business Value User Centered Approach
2 Work in Short Cycles Evidence based Decision Making
3 Hold Regular Retrospectives Improve the Product
4 Go and See Amplify Good Patterns
5 Test High Risk Hypothesis Focus on High value
6 Do Less More often Understand the Pain points
7 Work as a Balanced Team Small Team works one thing at a time
8 Radical Transparency Transparency through Rituals
9 Incentives Ship software to Deliver Customer Value
10 Learning a 1st Class Citizen of backlog Continuous Learning
Source: Jeff Gothelf : Lean vs Agile vs Design Thinking : https://www.youtube.com/watch?v=_4VPfmtwRac
Integrate the Principles Not Process
@arafkarsh arafkarsh
CAPABILITY CENTRIC DESIGN
• Business Functions
• Business process
• Team structure
18
1
@arafkarsh arafkarsh
From Object Modeling to Process Modeling
19
Developers with Strong Object
Modelling will experience
a big Mind Shift to
transition to Process based
modelling with Events.
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
@arafkarsh arafkarsh
Business Solution & Business Process
20
q Business Solution focuses on the entire Journey of
the User, which can run across multiple
Microservices.
q Business Solution comprises a set of Business
Processes.
q A specific Microservice functionality will be focused
on a Business Process / Concern.
q Business Processes can be divided further into
Business Functions
@arafkarsh arafkarsh
Levels of Data Flow Diagram
21
0-level DFD / System Context Design:
It represents the entire system as a single bubble and
provides an overall picture of the system.
1-level DFD:
It represents the main Processes of the system and
how they interact with each other.
2-level DFD:
It represents the sub-processes within each Main
Process of the system and how they interact with
each other.
0
1
2
Business
Solution
Business
Process
Business
Function
@arafkarsh arafkarsh
Business Solution & Business Process
22
Business Solution: Customer Dining Experience
Order Payment
Food Menu Kitchen
Dining
Browse Menu Order Dinner Dinner Served Get Bill Make Payment
User Journey with Story Map
Business Solution: User Shopping Experience
Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment
Catalogue Shopping Cart Order Payment
Customer
View Product
Search
@arafkarsh arafkarsh
Business Capability Centric Design
23
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 its own
Code Pipeline, Build Pipeline
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, leading to
bottlenecks and a lack of understanding of
the Business Domain.
QA Team
QA = Quality Assurance
PO = Product Owner
Vertically sliced Product Team
Front-End
Back-End
Database
Business
Capability 1
QA
PO Ops
Front-End
Back-End
Database
Business
Capability 2
QA
PO Ops
Front-End
Back-End
Database
Business
Capability - n
QA
PO Ops
@arafkarsh arafkarsh
From
Project Based
Activity
Oriented
To
Product Based
Outcome
Oriented
Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html
24
Traditional corporate IT organizations
operate in an activity-oriented manner
where they fund projects with set
time-spans.
Organizations that are outcome-oriented
align better with business outcomes, but
project-based funding undermines long-
term effectiveness.
Basing funding on products
centered around long-term
business capabilities
creates stable teams that
are aligned with business
needs.
Outcome-oriented thinking compels
business capability centered
organizations to consider more than
just delivering the scope, which is
where we want to be.
Project based Product based
Activity
Oriented
Outcome
Oriented
Business
Capability
Centric
@arafkarsh arafkarsh
User Stories
• User Stories
• Behavior Driven Design
• Writing Good Stories
• Estimate and Planning
• Case Study
25
Theme / Initiatives Epic User Story Sprint
@arafkarsh arafkarsh
User Story
26
Role-Feature-Reason Matrix
Story Card
These three elements
(WHO, WHAT, WHY)
are the building blocks
of User stories.
Element Example
Role WHO: As an e-Commerce Retailer
Feature WHAT:
I want to know who my Gold
Customers are
Reason WHY: So that I sell more
Element Definition
WHO:
Establishes the user or users or another
service.
WHAT:
Describes the Activity – Key Axis of the
Story. What the user does in the story.
WHY: This describes the purpose of the story.
Source: User Story A Pragmatic View, Page 9. Published 0ct 19, 2019
User stories are NOT
1. IEEE 830 Software Specs
2. Use Cases
Use Cases are a combination of User
Story and Acceptance Criteria
3. Scenarios
@arafkarsh arafkarsh
Acceptance Criteria / Behavior Driven Development
27
Source: https://dannorth.net/introducing-bdd/
Given Customer John Doe exists
When he buys products ABC for $1000 USD
Then He becomes a Gold Customer
BDD Construct
Acceptance Criteria
The definition of Done – As per Scrum
These three elements
(GIVEN WHEN THEN)
are the building blocks
of Acceptance Criteria.
Typical SDLC Life Cycle
Analyst Specifies the Use Case
Developer The developer builds software based on Specific
Usage scenarios with respect to the Use Case.
Tester Tester builds test cases based on Use Case
Scenarios and finds issues.
The Gaps identified in this
process are filled up by
linking the User Stories with
Acceptance Criteria.
@arafkarsh arafkarsh
INVEST in Good Stories
28
Source: INVEST in Good Stories, and SMART Tasks https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Term Description
I Independent
No overlapping but independent Stories. 3 Forms of Dependencies
1. Overlap 2. Order 3. Containment.
N Negotiable
A good story is not an explicit contract for features. A good story captures
the essence and not the details. Over a period, a Story may attract special
notes, test ideas and others. However, this is not required to prioritize and
schedule the story.
V Valuable
Story must be valuable to the customer.
E.g., (IRACIS) Increase Revenue, Avoid Cost, Improve Service.
E Estimable
An estimate (not necessarily precise) but to focus on priority and
implementation. You can use Function Points, COCOMO etc.
S Small
Any story that goes beyond few weeks is big and may be ambiguous. It’s
important to keep the Story small.
T Testable
A good story is testable. Testable story clearly establishes the spec from
Customer perspective.
@arafkarsh arafkarsh
3 C’s of User Stories
29
Card Conversation Confirmation
A Story card
provides the written
description of the
Story. It helps in
planning and
estimation.
The conversation is the
discussion between
Product Owners, Users,
and the Engineering
team to bring clarity to
the stories.
These are the
Acceptance Criteria
that need to be
satisfied to ensure
that the Story meets
all the requirements.
@arafkarsh arafkarsh
User Stories – Small Stories
30
• User Story should take a maximum of 3-5 person days
to complete the story. (From Analysis + Design +
Deploy + Test + Fix + Re-Deploy)
• User Stories can be smaller from a few hours to 1-2
Person days.
• Each story can have 3-7 Acceptance criteria.
• Sprint backlog will be having 6-10 stories.
• If a story survives more than 1 sprint, then the story
needs to break down into smaller stories.
Source: User Story A Pragmatic View, Page 78-80. Published 0ct 19, 2019
@arafkarsh arafkarsh
Features of BDD
31
• Focus on Behavior of the System
rather than tests.
• Collaboration between Business
Stake holders, Analysts,
Developers, QA.
• Ubiquitous Language
• Driven By Business Value
• Extends Test Driven Development
Source: https://cucumber.io/
Cucumber merges specification and
test documentation into one cohesive
whole.
@arafkarsh arafkarsh
User Story / Behavior Driven Development
32
Source: https://dannorth.net/introducing-bdd/
As an an e-Commerce Retailer
I want to know who my Gold Customers are
So that I sell more
Given Customer John Doe exists
When
he buys products ABC for $1000
USD
Then He becomes a Gold Customer
Role-Feature-Reason Matrix
As a Customer
I want to withdraw Cash from ATM
So that I don’t have to wait in line at the bank
Given
The account is in Credit
AND the Card is Valid
AND the dispenser contains Cash
Role-Feature-Reason Matrix
When The Customer requests Cash
Then
Ensure that the Account is debited
AND Ensure cash is dispensed
AND ensure that Card is returned.
BDD Construct
Acceptance Criteria
BDD Construct
Acceptance Criteria
User Story – 1 User Story – 2
@arafkarsh arafkarsh
Estimate – Story Points / Velocity
33
Story Point – An Ideal day’s work (8 Hour).
Means – no meetings, no emails, no phone calls etc.
1. Clarifying with Customer
2. Time to Develop
3. Write Test Cases
4. Testing
5. Deploy
6. Verify
The key over here is Reasonable rather than being Precise.
Source: User Stories Applied by Mike Cohn
Velocity
Velocity is the number of story points the team completes in an iteration.
@arafkarsh arafkarsh
Planning – MoSCoW Rules
34
Code Priority Description
Mo Must Have These features are fundamental to the Application
S Should Have These are important however; work arounds are available.
Co Could Have Can be left out if the developer runs out of time.
W Won’t Have Feature can be planned in a future release.
Release Plans
• All the story points prioritized as per the customer
• Story Points are mapped to a set of iterations.
• Estimated Velocity for each Iteration
• For Ex. If there are 200 Story Points
• 20 Story Points are allocated at each Iteration
• Then 10 iteration is required
@arafkarsh arafkarsh
Story Anti-Patterns
35
Anti Pattern Details
1 Too Small
Story 1. Export Report in Excel Format
Story 2. Export Report in PDF Format.
These can be combined to a Single story.
2 Interdependent Stories
This can cause planning issue. Remove the dependency or combine into a
Single Story.
3 Gold Plating Addition of un-necessary features by the developers.
4 Too Many Details Too much time is spent in gathering details.
5 Early UI Definition Including UI details too soon
6 Look Ahead Upfront Large Requirements gathering.
7 Splitting Too many stories
1. The Story is too large to fit into the iteration
2. Story contains High Priority and Low Priority items.
8 Unable to Prioritize Prioritization will be difficult if the business value can’t be determined
Source: User Stories Applied by Mike Cohn. Page 191
@arafkarsh arafkarsh
Why User Stories
• User stories emphasize verbal
communication.
• User stories are comprehensible by
everyone.
• User stories are the right size for planning.
• User stories work for iterative development.
• User stories encourage deferring detail.
• User stories support opportunistic design.
• User stories encourage participatory design.
• User stories build up tacit knowledge.
36
Source: User Stories Applied by Mike Cohn. Page 178
@arafkarsh arafkarsh
User Stories – Case Study
• Minimum Viable Product
• Case Study – eCommerce Application – ShopEasy
• User Journey and Story Map
37
@arafkarsh arafkarsh
What exactly
is a
Minimum
Viable
Product?
38
Let us understand this with a case study on eCommerce Shopping Portal.
@arafkarsh arafkarsh
Example 1: eCommerce / Checkout Experience
39
Theme / Initiative Epic User Story Sprint
ShopEasy / Checkout Experience
1. Simplify Checkout process
2. Multiple Payment options
3. Order Tracking
4. Inventory Management
5. Notifications
2. Multiple Payments
Release 1
1. Debit Card
Release 2
1. PayPal Payment
2. UPI Payment
Release 3
1. Credit Card
2. Net Banking
Stories
1. Credit Cards
2. Debit Cards
3. Net Banking
4. UPI Payment
5. PayPal Payment
6. Cash on Delivery
7. Save Payment info
@arafkarsh arafkarsh
Example 2: SCM / Inventory Streamlining
40
Theme / Initiative Epic User Story Sprint
SCM / Inventory Streamlining
1. Order Management
2. Inventory Management
3. Supplier Management
4. Notifications
2. Inventory Mgmt
Release 1
1. Add / Update Products
2. Stock Levels
Release 2
1. Stock Thresholds
Release 3
1. Inventory Reports
2. Stock Auto Refill
3. Stock Optimizations
Stories
1. Add / Update Products
2. Stock Levels
3. Inventory Reports
4. Stock Thresholds
5. Stock Optimizations
6. Stock Auto Refill
SCM = Supply Chain Management
@arafkarsh arafkarsh
Example 3: Space Shuttle Launch
41
Theme / Initiative Epic User Story Sprint
Shuttle Launch /
Pre-Launch Preparation
1. Develop & Test Shuttle Systems
2. Astronaut Training 2. Training
Release 1
1. Mission Training
Release 2
1. Emergency Training
Stories
1. Mission Training
2. Emergency Training
Shuttle Launch /
Launch Execution
1. Coordinate Launch Logistics
2. Monitor and Control Launch
Operations
Stories
1. Launch Sequence
2. Comm with Astronauts
2. Monitor &
Control
Release 1
1. Launch Sequence
2. Comm with
Astronauts
@arafkarsh arafkarsh
Example 4: Healthcare App
42
Theme / Initiative Epic User Story Sprint
Healthcare / We Care
1. Patient
2. Healthcare Staff
3. Appointments
4. Diagnosis
5. Lab
6. Pharmacy
7. Auth
4. Diagnosis
Release 1
1. Pre-Checkup
2. Search Medical
History
3. Diagnosis &
Prescription
Release 2
1. Prescribe for Lab
Tests
Stories
1. Pre-Checkup
2. Search Medical
History
3. Diagnosis &
Prescription
4. Prescribe for Lab
Tests
@arafkarsh arafkarsh
User Journey with Story Map & Release Cycles
43
1. Register 3. Make Appointment 4. Diagnosis and Prescription 6. Get Medicine
5. Lab Tests
Health Staff Appointment Pharmacy
Lab
Diagnosis
2. Search & Select Doctor
Patient
User Journey
Minimum Viable Product
Upload Medical
Docs
Add Doctor / Nurse
Cancel
Appointment
R2 Lab Tests
View Medical
History
Duty Calendar
R3 Reschedule
Register Search Doctor
Available Dates
Book Appointment Medical History
Check
Verify
Prescription
Pack
Medicines
R1
Pre-Checkup
Diagnosis &
Prescription
Appointment
Upload
Results
Schedule Duty Time
Make
Payment
Share Medical
Docs
R4 Appointment
Calendar
Make
Payment
View
Appointments
Email
SMS
@arafkarsh arafkarsh
Example 5: eCommerce Portal / Shop Easy
44
Theme / Initiative Epic User Story Sprint
eCommerce / Shop Easy
1. Customer Management
2. Search Product
3. Catalogue
4. Shopping Cart
5. Order Processing
6. Payments
2. Search Product
Release 1
1. Global Search
Release 2
1. Search by Brand
2. Search by Price
Range
Release 3
1. Search by Model
2. Search by Rating
Stories
1. Global Search
2. Search by Brand
3. Search by Price
Range
4. Search by Model
5. Search by Rating
@arafkarsh arafkarsh
User Journey with Story Map
45
Global Search
Search by Brand
Search by Price
Search by Model
Search by Rating
Product Details
Image Gallery
Product Reviews
User Shopping Experience
Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment
Catalogue Shopping Cart Order Payment
Customer
View Product
Search
User Journey
Add to Cart
Update Qty
Delete Item
Make
Payment
Confirm Order
Pay Credit Card
Pay Debit Card
Use PayPal
Select Address
Registration
@arafkarsh arafkarsh
User Journey with Story Map & Release Cycles
46
Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment
Catalogue Shopping Cart Order Payment
Customer
View Product
Search
User Journey
Search by Price Image Gallery Update Qty Use PayPal
R2
Search by Brand Product Reviews Pay Debit Card
R3
Global Search Product Details Add to Cart
Delete Item
Select Address Confirm Order
Pay Credit Card
Make
Payment
R1
Registration
Search by
Model
Search by
Rating
R4
Minimum Viable Product
@arafkarsh arafkarsh
Shopping Portal – Architects View
User Journey
47
@arafkarsh arafkarsh 48
Shopping Portal
/Web App
/Authentication
/product
/review
API Gateway
Nodes
Firewall
Web App Pod
Web App Pod
Web App
Service
N2
N1
Product Pod
Product Pod
Product Pod
Product
Service
N4
N3
MySQL
DB
Review Pod
Review Pod
Review Pod
Review
Service
N4
N3
N1
Users
Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP)
Mongo
DB
Mongo
DB
Auth Pod
Auth Pod
Auth / Authorize
Service
N3
N5
MySQL
DB
Generates
Token (JWT)
Services will
process requests
only if the token
is valid
@arafkarsh arafkarsh 49
Shopping Portal
/Customer
/Shopping Cart
/Order
Load Balancer
API Gateway
Nodes
Firewall
Order Pod
Order Pod
Order Pod
Order
Service
N4
N3
MySQL
DB
Users
Payment Pod
Payment Pod
Payment
Service
N4
N3
Cart Pod
Cart Pod
Cart Pod
Cart
Service
N1
N2
N2
Redis
DB
Services will
process requests
only if the token
is valid
External Payment Service
Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP)
Customer Pod
Customer Pod
Customer
Service
N1
N2
Redis
DB
@arafkarsh arafkarsh
Stories – Customer Registration
User Journey
50
@arafkarsh arafkarsh
Epic – Customer
51
As a Consumer
I want to register eCommerce Portal
So that I can buy products
Role-Feature-Reason Matrix
User Story – 1 : Registration
BDD Acceptance Criteria – 1: Save User
Given The fields First Name, Last Name, DOB
Address, Email Address, Phone No.
When The user enters values in the fields
First Name, Last Name, DOB Address,
Email Address, and Phone No.
Then If the following fields contain values
First Name, Last Name, Address, Email
Address, and Phone No.
AND Age is greater than 18, then
Save the Data.
BDD Acceptance Criteria – 2 : Generate Password
Given User Info Available
When The email address is a valid email id.
Then Generate the Password
AND Send mail with the user email address as
login id and the URL of the portal
AND Send the Password to a separate email
address.
AND Store data on mail status as mail sent or
failed.
BDD Acceptance Criteria – 3 : Resend Mail
Given User Registration mail status is available.
When The Mail status is equal to "Failed".
Then Send the mail again
AND store the attempt number.
@arafkarsh arafkarsh
Epic – Auth
52
As a Consumer
I want to login to eCommerce Portal
So that I can buy products
Role-Feature-Reason Matrix
User Story – 2 : Portal Login
BDD Acceptance Criteria – 1 : Authentication
Given The user clicks the login page, and the portal
goes to the login page with
the fields login id and continue button.
When The user enters the login id and clicks the
continue button, and the page shows the
password page.
AND the user enters the Password and clicks
the sign-in button.
Then The system validates the credentials, and
IF the credentials are valid, then the user is
allowed to do the shopping.
Else access denied message is shown.
BDD Acceptance Criteria – 2 : Authentication
Given The Request is authenticated.
When The Input contains the login id and
Password.
Then The system validates the credentials, and
IF the credentials are valid, then the user
is allowed to do the shopping.
Else access denied message is shown.
@arafkarsh arafkarsh
Stories – Shopping : Sprint R1
User Journey
53
@arafkarsh arafkarsh
Epic – Search (Product)
54
As a Consumer
I want to search for a product
So that I can buy products
Role-Feature-Reason Matrix
User Story – 1 : Global Search
BDD Acceptance Criteria – 1 : Global Search
Given The user logged into the portal, and the
product search page was available.
When The user enters the product name and
clicks search
Then The system search for the Product, and
IF it matches the products in the DB, then
the service returns the result, which
contains the following fields for all the
records: Product Name, Product Model,
Price, Description, Product Image
ELSE returns zero records.
BDD Acceptance Criteria – 2 : Global Search
Given The Request is authenticated.
When Input contains Product Name
Then The system search for the Product, and
IF it matches the products in the DB,
then the service returns the result,
which contains the following fields for
all the records: Product Name, Product
Model, Price, Description, Product
Image
ELSE returns zero records.
@arafkarsh arafkarsh
Epic – Product Page
55
As a Consumer
I want to check a Product
So that I can buy the Product
Role-Feature-Reason Matrix
User Story – 1 : Show Product
BDD Acceptance Criteria – 1: Show Product
Given The user logs into the portal, a Product is
searched, and results are available.
When The user then clicks a product for product details
Then The system will show product details based on
the product ID with following details.
Product Name, Product Rating, Price, Product
Description and Image, and buttons to
" Add to Cart" and "Buy Now."
IF the Product is not available, then the system
will show the error "Selected Product details are
not available."
BDD Acceptance Criteria – 2: Retrieve Product
Given The Request is authenticated
When The Input contains Product id
Then The system will return the product
details based on the product ID with
the following details.
Product Name, Product Rating, Price,
Product Description, and Image
IF the Product is not available, then
the system will show the error
"Selected Product details not
available."
@arafkarsh arafkarsh
Epic – Shopping Cart
56
As a Consumer
I want to Add a Product to the Cart
So that I can buy the Product
Role-Feature-Reason Matrix
User Story – 1 : Add to Cart
BDD Acceptance Criteria – 1: Add to Cart
Given The user logs into the portal, a Product is
selected, and Product details are available.
When The user then clicks Add to Cart Button.
Then The system will add the Item (Product) to
the Cart and Update the Item counter in the
Cart Icon
AND Saves the Cart information in the DB,
AND if the save fails, the system shows an
Error "Unable to Add Product to the Cart."
BDD Acceptance Criteria – 2: Save Cart
Given The Request is authenticated.
When The Input contains the user login id
and Product id.
Then The system will add the Item
(Product) to the Cart Saves the Cart
information in the DB
AND if the save fails, the system
shows an Error "Unable to Add
Product to the Cart."
@arafkarsh arafkarsh
Epic – Shopping Cart
57
As a Consumer
I want to see all the items in the Cart
So that I can buy the Product
Role-Feature-Reason Matrix
User Story – 2 : Show Cart
BDD Acceptance Criteria – 1: Show Cart
Given The user logged into the portal.
When The user then clicks Cart.
Then The system retrieves all the Cart Items from the
DB and shows in the UI the following details
Product Item Name, Thumb scale picture,
Quantity, Price, and Delete Button to delete the
item and Sum total of Items and Price.
IF the Cart is empty (No Records in the DB), then
it shows an Empty Cart with the message "Cart is
Empty."
BDD Acceptance Criteria – 2: Show Cart
Given The Request is authenticated.
When The Input contains the user login id.
Then The system retrieves all the Cart
Items from the DB and shows in the
UI the following details.
Product Item Name, Thumb scale
picture, Quantity, Price
IF the Cart is empty (No Records in
the DB), then it shows an Empty
Cart with the message “Cart is
Empty."
@arafkarsh arafkarsh
Epic – Shopping Cart
58
As a Consumer
I want to Delete a Product from the Cart
So that I can buy other items in the Cart.
Role-Feature-Reason Matrix
User Story – 3 : Delete from Cart
BDD Acceptance Criteria – 1: Delete From Cart
Given The user logs into the portal and clicks the
Shopping Cart, and the cart displays all the items.
When The user then clicks Delete Button for a Product.
Then The system will delete the Item (Product) from
the Cart and update the Item counter in the Cart
Icon.
AND deletes an item from the Cart DB
AND if the delete fails, the system shows an
Error" Unable to Delete Product from the Cart."
BDD Acceptance Criteria – 2: Delete item
Given The Request is authenticated.
When The Input contains the user login id
and Product id.
Then The system will delete the Item
(Product) from the cart DB
AND if the delete fails, the system
shows an Error "Unable to Delete
Product from the Cart."
@arafkarsh arafkarsh
Epic – Customer
59
As a Consumer
I want to Select Shipping Address
So that I can ship the items to that Address
Role-Feature-Reason Matrix
User Story – 3 : Select Address BDD Acceptance Criteria – 1 : Show Address
Given The user is on the Shopping Cart Page.
When The user Clicks Proceed to Buy Button.
Then The System shows the Available Addresses
for Shipping.
BDD Acceptance Criteria – 2 : Select Address
Given The user in the Shopping Cart Page with
Available Shipping Address
When The user Selects the Address and Clicks Proceed
to Buy.
Then The System saves the Temp Order details from
Items from Shopping and Selected Shipping
Address
AND these details are valid only for the user
session. If the order is not placed, Temp Order
items will be put back in Cart DB.
BDD Acceptance Criteria – 3 : Save Temp Order
Given The Request is authenticated.
When The input contains the user login id, items,
and shipping address.
Then The System saves the Temp Order details
from Items from Shopping and Selected
Shipping Address
AND these details are valid only for the user
session. If the order is not placed, Temp
Order items will be put back in Cart DB.
@arafkarsh arafkarsh
Epic – Order : Credit Card
60
As a Consumer
I want to Process the Order
So that I can buy Products
Role-Feature-Reason Matrix
User Story – 1 : Process Order
BDD Acceptance Criteria – 1 : Add Payment
Given The user is on the Order Page with Items and
selected Shipping Address.
When The user Selects the Payment Option As a
Credit Card
AND Input the Credit Card Details in the
following fields Card Name, Card No. Expiry
Date (MM/YYYY), CVV Number.
Then The System Validates the Credit Card Number
and the Expiry Date, Card Name & CVV.
These data Must NOT be Null
IF Invalid, THEN
Systems say invalid Payment details, ELSE
Saves the info and proceeds with the payment.
BDD Acceptance Criteria – 3 : Save Payment
Given The Request is authenticated.
When The input contains the user login id, order id, and
payment details (card number only last four digits).
Then The System Validates the Credit Card Number and
the Expiry Date, Card Name & CVV.
These data Must NOT be Null
IF Invalid, THEN
Systems say invalid Payment details, ELSE
Saves the following info Card Name, Card Number
(only last 4 digits), Expiry Date and
proceeds with the payment.
BDD Acceptance Criteria – 3 : Payment Gateway
Given The Request is authenticated.
When The input contains Valid payment details.
Then The Request with the valid Payment Details, the
System calls the External Payment Service for
Payment Processing and Returns the Result to the
Calling System.
@arafkarsh arafkarsh
Epic – Payment
61
As a Consumer
I want to Make a Payment
So that I can buy Products
Role-Feature-Reason Matrix
User Story – 1 : Make Payment
BDD Acceptance Criteria – 1 : Process OTP
Given The user Enters the Payment Details and
Clicked Proceed to Buy, and the System
shows the Payment Service Page.
When The user Enters One Time Password (OTP)
and clicks Proceed.
Then The System Sends the OTP to the External
Payment Gateway, and the result is returned
to the Caller.
BDD Acceptance Criteria – 2 : Order Status
Given The Request is authenticated.
When The input contains Payment Status.
Then IF the Payment is successful,
the Order Status is changed to Successful
ELSE,
the items are returned to the Cart.
@arafkarsh arafkarsh
Stories – Shopping : Sprint R2
User Journey
62
@arafkarsh arafkarsh
Epic – Auth
63
As a Consumer
I want to Reset the Password
So that I can log in to Portal.
Role-Feature-Reason Matrix
User Story – 3 : Forgot Password
BDD Acceptance Criteria – 1 : Forgot Password
Given The Request is authenticated.
When The Input contains the login id and
password.
Then The System validates the email address and
the security question
AND if they are valid, then the system re-
generates the password
AND Stores the password (Hashed)
AND send the new password in an email to
the user.
AND Stores the status of email delivery.
BDD Acceptance Criteria – 2 : Forgot Password
Given The login page contains Forgot Password
link.
When The user clicks Forgot Password link then
the page shows Forgot Password Page,
AND the user enters their Email Address
and clicks the continue button
AND then, the page goes to the security
page, and the user enters the security
question and clicks the reset password
button.
Then The System validates the email address
and the security question
AND if they are valid, then the system re-
generates the password
AND Stores the password (Hashed)
AND send the new password in an email
to the user.
AND Stores the status of email delivery.
@arafkarsh arafkarsh
Epic – Search (Product: Price Range)
64
As a Consumer
I want to search for a Product within a price range
So that I can buy Products.
Role-Feature-Reason Matrix
User Story – 2 : Search By Price Range
BDD Acceptance Criteria – 1: By Price Range
Given The user logged into the Portal, and the product
search page was available.
When The user enters the Product name
AND the Price Range & clicks search.
Then The System search for the Product within the Price
Range, and if it matches the products in the DB,
then the service returns the result, which contains
the following fields for all the records: Product
Name, Product Model, Price, Description, and
Product Image. Else returns zero records.
BDD Acceptance Criteria – 2: By Price Range
Given The Request is authenticated.
When The Input contains the Product name
AND the Price Range.
Then The System search for the Product within
the Price Range, and if it matches the
products in the DB, then the service
returns the result, which contains the
following fields for all the records:
Product Name, Product Model, Price,
Description, and Product Image.
Else returns zero records.
@arafkarsh arafkarsh
Epic – Product Page
65
As a Consumer
I want to check a Product
So that I can buy the Product.
Role-Feature-Reason Matrix
User Story – 2 : Show Product with Image Gallery
BDD Acceptance Criteria – 1: Show Product
Given The user logs into the Portal, a Product is searched,
and results are available.
When The user then clicks a product for product details.
Then The System will show product details based on the
product ID with the following information.
Product Name, Product Rating, Price, Product
Description and Image Gallery, and buttons to
"Add to Cart" and "Buy Now."
If the Product is not available, then the System will
show an error "Selected Product details are not
available."
BDD Acceptance Criteria – 2: Retrieve Product
Given The Request is authenticated.
When The Input contains the product id.
Then The System will return the product
details based on the product ID with the
following information.
Product Name, Product Rating, Price,
Product Description, and Image Gallery
If the Product is not available, then the
System will show an error
"Selected Product details not available."
@arafkarsh arafkarsh
Epic – Shopping Cart
66
As a Consumer
I want to Update the Quantity of a Product in the Cart
So that I can buy the Product.
Role-Feature-Reason Matrix
User Story – 3 : Update the Cart
BDD Acceptance Criteria – 1: Update Quantity
Given The user logs into the Portal and clicks the
Shopping Cart, and the Cart displays all the items.
When The user then inputs the Quantity for a Product.
Then The System ensures that the Quantity is greater
than ZERO
AND the System will update the Quantity in the
cart DB.
AND if there is an error in updating System will
show "Unable to update the Quantity."
BDD Acceptance Criteria – 2: Update Quantity
Given The Request is authenticated.
When The Input contains the user login id,
product id, and Quantity.
Then The System ensures that the
Quantity is greater than ZERO
AND the System will update the
Quantity in the cart DB.
AND if there is an error in updating
System will show
"Unable to update the Quantity."
@arafkarsh arafkarsh
Epic – Order : PayPal
67
As a Consumer
I want to Process the Order
So that I can buy Products
Role-Feature-Reason Matrix
User Story – 1 : Process Order
BDD Acceptance Criteria – 1 : Add Payment
Given The user is on the Order Cart Page with
Items and selected Shipping Address.
When The user Selects Payment Option As PayPal
AND Input the PayPal Details.
Then The System Validates the PayPal Details
IF Invalid, Then the System returns "Invalid
Payment details."
ELSE
Saves the info and proceeds with Payment.
BDD Acceptance Criteria – 3 : Save Payment
Given The Request is authenticated.
When The input contains the user login id, order
id, and payment details (PayPal Details).
Then The System Validates the PayPal Details
IF Invalid, Then the System returns "Invalid
Payment details."
ELSE
Saves the info and proceeds with Payment.
BDD Acceptance Criteria – 3 : Payment Gateway
Given The Request is authenticated.
When The input contains Valid payment details.
Then The Request with the Valid Payment Details,
the System calls the External Payment
Service for Payment Processing and Returns
the Result to the Calling System.
@arafkarsh arafkarsh 68
User Journey / Story Map & Release Cycles
Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment
Catalogue Shopping Cart Order Payment
Customer
View Product
Search
User Journey
Search by Price Image Gallery Update Qty Use PayPal
R2
Global Search Product Details Add to Cart
Delete Item
Select Address Confirm Order
Pay Credit Card
Make
Payment
R1
Registration
Minimum Viable Product
Scrum Sprint Cycle
Search by Price Image Gallery Update Qty Use PayPal
Kanban Cycle: Each of the Stories can be released without waiting for other stories to be completed resulting in
Shorter Releases as all the stories are independent!
@arafkarsh arafkarsh
Capability Centric Design Summary
69
1. Business Solutions
1. Business Process
2. Business Capabilities
2. Business Driven Teams
(From Specs to Ops)
3. Outcome Oriented instead
of Activity Oriented.
4. User Stories
1. Story Points
2. Velocity
5. Behavior Driven Design
Business Solution
Business
Process 1
Business
Process 2
Business
Process n
Business Capability 1
Business Capability 2
Business
Capability n
User Stories BDD
Story Points
MVP – User Journey
@arafkarsh arafkarsh
Agile
• Agile Values
• Scrum
• Scrum Rules
• Kanban Boards and cards
• Kanban vs Scrum
• Benefits of kanban
70
@arafkarsh arafkarsh
Agile Values
71
INDIVIDUALS AND
INTERACTIONS
OVER PROCESSESS
AND TOOLS
WORKING SOFTWARE COMPREHENSIVE
DOCUMENTATION
OVER
CUSTOMER
COLLABORATION
OVER CONTRACT
NEGOTIATION
RESPONDING
TO CHANGE OVER FOLLOWING
A PLAN
Source: Agile Manifesto - https://www.scrumalliance.org/resources/agile-manifesto
@arafkarsh arafkarsh
Scrum
72
Daily
Scrum
Sprint
Review
Sprint
Retrospective
Sprint
Planning
4 – 8 People
Max
8 Hours
Max
15 Mins
Multiple
increments
within a
Sprint
1 Month
Release
Increment
Stories
Planned
for a
Sprint
Sprint
Backlog
Product
Backlog
Complete
Specs
@arafkarsh arafkarsh
Scrum Events
73
Sprints encompass all the work necessary to achieve the Product Goal, including
Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives.
SPRINT
SPRINT PLANNING
Max : 8 Hours
1. Why is Sprint Valuable?
2. What can be Done in this Sprint?
3. How will the chosen work get done?
Source: https://www.scrum.org/resources/what-is-scrum
DAILY SCRUM
Max : 15 mins
The Daily Scrum seeks to examine the progress made toward the Sprint Goal and adjust
the Sprint Backlog as needed, modifying the planned work for the upcoming period.
SPRINT REVIEW
During the Sprint Review, the Scrum Team inspects the Sprint's outcome and
determines any necessary adaptations for the future. They present their work results
to critical stakeholders, and the group discusses progress toward the Product Goal.
SPRINT
RETROSPECTIVE
The Sprint Retrospective aims to plan ways to increase quality and effectiveness.
@arafkarsh arafkarsh
Scrum Artifacts
74
PRODUCT BACKLOG
The Product Backlog is an emergent, ordered list of what is needed to improve the
product. It is the single source of work undertaken by the Scrum Team.
SPRINT BACKLOG
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time
picture of the work that the Developers plan to accomplish during the Sprint in order to
achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the
Sprint as more is learned. It should have enough detail that they can inspect their
progress in the Daily Scrum.
INCREMENT
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is
additive to all prior Increments and thoroughly verified, ensuring that all Increments
work together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is
presented at the Sprint Review
Source: https://www.scrum.org/resources/what-is-scrum
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and
adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information
so that everybody has the same understanding of the artifact
@arafkarsh arafkarsh
Sprint
Backlog
75
Source: https://www.scrum.org/resources/what-is-scrum
@arafkarsh arafkarsh
Rules of Scrum
• Sprint Planning meeting is held at the start of Each Sprint.
• Each Sprint must deliver working and fully tested code that
demonstrate value to the customer.
• Product Owner Prioritizes the Product Backlog.
• Team Collectively selects the Amount of Work brought into
Sprint
• Once a sprint begins, only the team may add to the Sprint
backlog.
• A Short Scrum meeting is done every day.
76
Source: User Stories Applied by Mike Cohn. Page 204
@arafkarsh arafkarsh
Scrum Values
77
@arafkarsh arafkarsh
What is Kanban
78
Kanban is a method for managing the creation
of products with an emphasis on
• continual delivery (Daily / Hourly) while
• not overburdening the development
team.
Like Scrum, Kanban is a process designed to
help teams work together more effectively.
Kanban is a visual management method that was developed by Toyota in
the early 1940s.
Kanban in Japanese means Card
Microsoft Xbox One
Team does multiple
Daily releases using
Kanban.
@arafkarsh arafkarsh
Kanban History
79
Introduced by Toyota in Manufacturing - 1940s
It all started in the early 1940s. The first Kanban system
was developed by Taiichi Ohno (Industrial Engineer and
Businessman) for Toyota automotive in Japan. It was
created as a simple planning system, the aim of which
was to control and manage work and inventory at every
stage of production optimally.
Source: https://www.digite.com/kanban/what-is-kanban/
David J. Anderson who was the first to apply the concept to IT, Software
development and knowledge work in general in the year 2004.
@arafkarsh arafkarsh
Three Principles of Kanban
80
Source: https://resources.collab.net/agile-101/what-is-kanban
• Visualize your current workflow: Seeing
all items in the context of one another
can provide valuable insights.
• Limit work in progress (WIP): This
approach helps balance the flow-based
method, preventing teams from starting
and committing to too much work
simultaneously.
• Improve flow: When a task is
completed, the next highest-priority
item from the backlog is pulled into
action.
To Do In Progress Done
@arafkarsh arafkarsh
Kanban Board
81
Backlog Work breakdown Work In Progress Done
Active Done Active Done
Track
Task blocked
due to
Dependency.
Once the
dependent
Task is ready,
the blocked
Task will be
moved to
Active State.
To Do List
Max items in WIP must be
1.4x of total Resources
A Backlog item is broken down
into tasks, and each Task
should take at most 1-3 days at
max.
It's a good practice to keep all
the tasks of similar size.
Tasks are assigned to
respective team members.
@arafkarsh arafkarsh
6 Core Practices in Kanban
82
1. Visualize the flow of work
2. Limit WIP (Work in Progress)
3. Manage Flow
4. Make Process Policies Explicit
5. Implement Feedback Loops
6. Improve Collaboratively, Evolve Experimentally
Source: https://www.digite.com/kanban/what-is-kanban/
@arafkarsh arafkarsh
Release Cycles
83
Kanban
Preparation
Requirements
Design
Development
Testing
Release
1 Day – 1 Weeks Cycle
Scrum
1 Month (Max) Cycle
1 or 2 Weeks Cycle
also allowed
@arafkarsh arafkarsh
Similarities between Kanban and Scrum
84
Task Breakdown Continuous Improvement Visible Workflow
Both Scrum and Kanban supports Large Complex work to be broken down to smaller tasks and
completed efficiently. Both place high focus on Continuous Improvement and process optimization
and support a highly visible (Task) Workflows for the visibility to all the stake holders.
@arafkarsh arafkarsh
Kanban Vs. Scrum
85
Kanban Scrum
Roles &
Responsibilities
No prescribed roles
Pre-defined roles of Scrum master,
Product owner and team member
Delivery Timelines Continuous Delivery (Daily/Hourly) Time boxed sprints (2-4 Weeks)
Delegation &
Prioritization
Work is pulled through the system
(single piece flow)
Work is pulled through the system
in batches (the sprint backlog)
Modifications Changes can be made at any time No changes allowed mid-sprint
Measurement of
Productivity
Cycle time Velocity
When to Use?
More appropriate in operational
environments with a high degree of
variability in priority
More appropriate in situations
where work can be prioritized in
batches that can be left alone
Source: https://leankit.com/learn/kanban/kanban-vs-scrum/
@arafkarsh arafkarsh
Benefits of Kanban
86
• Shorter cycle times can deliver features faster.
• Responsiveness to Change:
• When priorities change very frequently, Kanban is ideal.
• Balancing demand against throughput guarantees that most
the customer-centric features are always being worked.
• Requires fewer organization / room set-up changes to get
started
• Reducing waste and removing activities that don’t add value to
the team/department/organization
• Rapid feedback loops improve the chances of more motivated,
empowered and higher-performing team members
@arafkarsh arafkarsh
Agile is
not
what
you do.
Agility is
how
you do
it.
87
@arafkarsh arafkarsh
Architecture Styles/Patterns
• Layered Architecture
• Component Based Architecture
• Service Oriented Architecture
• Service Based Architecture
• Micro Kernel Based Architecture
• Domain Drive Design Intro
• Event Sourcing Intro
88
2
@arafkarsh arafkarsh 89
Architecture Styles, Patterns & Design Patterns
• Component-based
• Client-server
• Event-driven
• Layered Architecture
• Monolithic application
• Plug-ins
• Publish-subscribe
• Service Based
• Service-Oriented
• Microservices
Architecture Style:
1. How to Organize the Code,
2. Creating high-level modules
& layers and how they
interact each other.
Architecture Patterns:
A Recurring solution to a
recurring problem.
Providing the Solution to
an Architecture Style. Ex.
How a request is processed
from the outer layer to
inner layer.
• Three Tier
• Micro Kernel
• Model View Controller
• Event Sourcing and CQRS
• Domain Driven Design
Design Patterns:
Scope of the Design
Patterns is much
narrower compared to
an Architecture Pattern.
It focuses on
instantiating an object,
behavior of the object.
• Adapter
• Builder / Factory
• Saga
• Repository
• Aggregate Root
Wider Scope Narrow Scope
@arafkarsh arafkarsh
Component Based Architecture
90
1. Logical Units: Breaking the App into well defined logical units.
2. Communication: Components communicate using a COM/DCOM, EJB, CORBA, RMI
and other protocols or standard API contracts.
3. Reusability: A well defined component can be reused and self deployable unit.
4. Maintenance: Easy to change and upgrade the components without affecting the
whole system
5. Ease of Development: With well defined API contracts, it’s easy to develop a
component to do a specific task without impacting other parts of the system.
6. Ease of Deployment: It is easy to upgrade the existing version of the component
with the latest version without impacting other parts of the system (Provided
backward compatibility is maintained).
@arafkarsh arafkarsh
o A network separates all the
3 Layers, and by Value, data
is transferred.
o You can upgrade a layer
without worrying about the
impact on the other layer as
long as the contract
between the layers is intact.
o The logic Tier can be further
divided into
1. Web Services Layer
2. Business Layer
3. Database Layer
Layered Architecture Style
91
UI Layer
WS
BL
DL
Database
Shopping Cart
Order
Customer
Product
John J. Donovan developed it in Open Environment Corporation
(OEC), a tools company he founded in Cambridge, Massachusetts.
3 Tier Architecture Pattern
https://professordonovan.com/open-environment-corporation
Presentation Tier
UI is the topmost level of the Application. The
primary function of the UI is to give a better
Human-Machine Interaction.
Logic Tier
The Logic Tier is the intermediary between the Presentation
and Database Tier. Its responsibilities include Interpreting
commands, Making logical decisions and evaluations,
Performing calculations, and Facilitating the movement and
processing of data between the surrounding layers.
Database Tier
The information is stored and retrieved from the Database
Tier. The data is sent back to the Logic Tier for processing
and then back to Presentation Tier for the User to take
action.
@arafkarsh arafkarsh
Service Based Architecture
92
SOA and Microservices based on Service Based Architecture
1. Distributed Computing: Common thing in Service based architecture is
distributed computing.
2. Communication: Services communicate using a Remote Access Protocol (SOAP,
REST, RMI, JMS, Message Queues, AMQP (Advanced Message Queuing Protocol)
3. Service Contracts: They are based on XML, JSON, ProtoBuf, etc. Contract
versioning is a crucial aspect of contracts and their future evolution.
4. Availability and Responsiveness: Availability ensures that there is no single point
of failure and Responsiveness ensures that the Service Responds on time.
5. Security: As Services are independent components, security and access controls
must be taken care of. JSON Web Token is a popular standard.
6. Transactions: Transaction management is a Big challenge in Service-based
Architecture. 2 Phase Commit, or Saga Design Patterns, focus on addressing
these challenges.
@arafkarsh arafkarsh
SOA – Service Oriented Architecture
93
UI Layer
Database
Shopping Cart
Order
Customer
Product
Enterprise Service
Bus
Messaging
REST / SOAP
HTTP
MOM
JMS
ODBC / JDBC
Translation
Web Services
XML
WSDL
Addressing
Security
Registry
Management
Producers
Shared
Database
Consumers
3rd Party
Apps
Smart Pipes
Lot of Business logic
resides in the Pipe
Traditional Monolithic App with SOA
Service properties
1. It logically represents a
business activity with a
specified outcome.
2. Each Service is self-contained.
3. Each Service is a Blackbox to
the Service Consumer.
4. A Service can contain other
Services too.
5. Service Can be re-used. For Ex
Customer Service can be used
by multiple Apps.
Source: https://dzone.com/articles/service-oriented-architecture-a-dead-simple-explan
@arafkarsh arafkarsh
The microkernel architecture pattern
consists of two types of architecture
components:
1. a core system and
2. plug-in modules.
Application logic is divided between
1. independent plug-in modules
2. and the basic core system, providing
3. extensibility,
4. flexibility, and
5. isolation of application features
6. and custom processing logic
Micro Kernel Architecture Pattern
94
Source: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html
Plug-In
Component
Plug-In
Component
Plug-In
Component
Core
System
Plug-In
Component
Plug-In
Component
Plug-In
Component
@arafkarsh arafkarsh
DDD: Bounded Context – Strategic Design
95
• Bounded Context is a Specific Business Process / Concern.
• Components / Modules inside the Bounded Context are context specific.
• Multiple Bounded Contexts are linked using Context Mapping.
• One Team assigned to a Bounded Context.
• Each Bounded Context will have it’s own Source Code Repository.
• When the Bounded Context is being developed as a key strategic
initiative of your organization, it’s called the Core Domain.
• Within a Bounded Context the team must have same language called
Ubiquitous language for Spoken and for Design / Code Implementation.
Domain Driven Design
@arafkarsh arafkarsh 96
User Journey X
Bounded
Context
Bounded
Context
Bounded
Context
User Journey Y
Bounded
Context
Bounded
Context
Bounded
Context
Product
Catalogue
Reviews
Product
Order Item
Shipping
Methods
Address
Payments
Order
Items
Category
Inventory
Event
Cart Items
Wish List Price Event
Category
Order
Added From
Cart
uses
uses
Understanding the Bounded Context
(DDD) of an E-Commerce Application.
Product
Context
Order
Context
Cart Context
Product
Catalogue
Reviews
Product
Order Item
Shipping
Methods
Address
Payments
Order
Items
Category
Inventory
Event
Cart Items
Wish List Price Event
Category
Order
Added From
Cart
uses
uses
Can we carve out another Microservice from the
existing Microservices (Product, Order, Cart)?
Monolithic
Data Models
DDD: App User’s Journey
& Bounded Context
@arafkarsh arafkarsh
Domain Driven Design – Tactical Design
97
Source: Domain-Driven Design Reference by Eric Evans
@arafkarsh arafkarsh
DDD: Understanding Aggregate Root
98
Order
Customer
Shipping
Address
Aggregate
Root
Line Item
Line Item
Line Item
*
Payment
Strategy
Credit Card
Cash
Bank Transfer
Source: Martin Fowler : Aggregate Root
• An aggregate will have one of its component
objects be the aggregate root. Any references
from outside the aggregate should only go to the
aggregate root. The root can thus ensure the
integrity of the aggregate as a whole.
• Aggregates are the basic element of transfer of
data storage - you request to load or save whole
aggregates. Transactions should not cross
aggregate boundaries.
• Aggregates are sometimes confused with
collection classes (lists, maps, etc.).
• Aggregates are domain concepts (order, clinic visit,
playlist), while collections are generic. An
aggregate will often contain multiple collections,
together with simple fields.
125
Domain
Driven
Design
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
@arafkarsh arafkarsh
Event Sourcing Intro
99
Standard CRUD Operations – Customer Profile – Aggregate Root
Profile
Address
Title
Profile Created
Profile
Address
New Title
Title Updated
Profile
New
Address
New Title
New Address added
Derived
Profile
Address
Notes
Notes Removed
Time T1 T2 T4
T3
Event Sourcing and Derived Aggregate Root
Commands
1. Create Profile
2. Update Title
3. Add Address
4. Delete Notes
1
Events
1. Profile Created Event
2. Title Updated Event
3. Address Added Event
4. Notes Deleted Event
2
Profile
Address
New Title
Current State of the
Customer Profile
3
Snapshot
Event store
Single Source of Truth
Greg
Young
@arafkarsh arafkarsh 100
Event Sourcing & CQRS
(Command and Query Responsibility Segregation) Presentation Tier
Logic Tier
• Request Validations
• Commands / Domain Logic
• Data Persistence
Database Tier
The same Schema
is used for both
Read and Write.
Read Model
Write Model
Queries
(DTOs)
Presentation Tier
Logic Tier
• Request Validations
• Commands / Domain Logic
• Data Persistence
Database Tier
Read & Write Schema
are different
Separate Process
Updates the Read DB
Write
Model
Queries
(DTOs)
Read
Model
• In traditional data management systems, both
commands (updates to the data) and queries
(requests for data) are executed against the
same entities in a single data repository.
• CQRS is a pattern segregating the operations
that read data (Queries) from the operations
that update data (Commands) using separate
interfaces.
• CQRS should only be used on specific portions
of a system in Bounded Context (in DDD).
• CQRS should be used along with Event
Sourcing.
MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx |
Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
Axon
Framework
For Java
Java Axon Framework Resource : http://www.axonframework.org
CQS: Bertrand Meyer
Greg
Young
@arafkarsh arafkarsh
Distributed Tx: SAGA Design Pattern instead of 2PC
101
Long-Lived Transactions (LLTs) hold onto DB resources for relatively long periods, 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 Reserved
T1
Room Payment
T2
Seat Reserved
T3
Ticket Payment
T4
Cancelled Room Reservation
C1
Cancelled Room Payment
C2
Cancelled Ticket Reservation
C3
Error
Error
Error
@arafkarsh arafkarsh
API Architecture Maturity Levels
102
Source: https://www.apiscene.io/lifecycle/7-layers-of-api-architecture-maturity/
• REST & gRPC – API Communication in Microservices: https://www.apiscene.io/lifecycle/rest-grpc-api-communication-in-microservices/
• A Postman API Governance Collection: https://www.apiscene.io/lifecycle/a-postman-api-governance-collection/
• Impact of Distributed Architecture to API Lifecycle: https://www.apiscene.io/lifecycle/what-is-the-impact-of-distributed-architecture-to-api-lifecycle/
•
@arafkarsh arafkarsh
Architecture Styles Summary
103
1. Architecture Style
1. Component Based
2. Client Server
3. Event Driven
4. Layered Architecture
5. Monolithic
6. Pub / Sub Architecture Style
7. Service Based
1. Service Oriented
2. Microservices
2. Architecture Patterns
1. Three Tier
2. Micro Kernel
3. Domain Driven Design
4. Event Sourcing and CQRS
3. Design Patterns
1. Saga
2. Repository
3. Aggregate Root
@arafkarsh arafkarsh
MICROSERVICES TECHNOLOGY LANDSCAPE
1999
Commercial
Virtual Machine
2003
VM Monitor
Hypervisor
2004
Architecture Pattern
Domain
Driven Design
2006
Cloud Services
Amazon AWS
2013
Containers
Docker
2014
Container
Orchestrator
Kubernetes
2005
Architecture Pattern
Event Sourcing
& CQRS
1995s 2020s
2000s
Cloud Native Apps
Infrastructure Evolution
1. Virtual Machines
2. Containers
3. Kubernetes (Orchestrator)
4. Istio (Service Mesh)
5. Kafka (Messaging)
Architecture Patterns
1. API Gateways / LB
2. Service Discovery
3. Event Driven
4. Service Mesh
5. Domain Driven Design
6. Event Sourcing & CQRS
7. Reactive Programming
8. Distributed Tx
2015
Service Mesh
Istio
2011
Messaging
Kafka
1998
Architecture Style
3 Tier Architecture
2003
Architecture Style
SOA
2020
Service Mesh
Open Service Mesh
2007
Linux Kernel
cgroups
2008
Cloud Services
Google Cloud
2010s
2010
Cloud Services
Microsoft Azure
2011
Hybrid Cloud Services
RedHat OpenShift
1999
Software Process
XP (Agile)
1987
Design Pattern
Saga Pattern
2005s 2015s
2004
Software Process
Kanban
1985s
2010
Cloud Services
OpenStack
2009
PaaS Services
Cloud Foundry
@arafkarsh arafkarsh
Composable Enterprise Architecture
105
A composable enterprise is an
organisation that delivers
business outcomes and adapts
to the pace of business
change.
It does this through the
assembly and combination of
Packaged Business Capabilities
(PBCs).
PBCs are application building
blocks that have been
purchased or developed.
Source: Gartner: Future of Applications: Delivering the Composable Enterprise | Why does it matter?
APIs Event Channels
Composable Enterprise
Business
Capabilities
Business
Capabilities
Business
Ecosystems
My
Application
Experience
Digital Business
Technology Platform
Source: Gartner
Future of Applications
@arafkarsh arafkarsh
Composable Enterprise Architecture
106
Source: Gartner: Future of Applications: Delivering the Composable Enterprise | Why does it matter?
On Demand
Scalability
Service & Apps
Integrated
with Clients &
Devices
Automated
On Demand
Services
Self Service
Options for
App & Data
MASA
Mesh App & Service
Architecture
Enterprise Data
Available, Accessible, &
Integrated into Data Flow
Delivers > Packaged Business Capabilities
@arafkarsh arafkarsh
Domain Driven Design
• Strategic Design
• Tactical Design
o Ubiquitous Language
o Bounded Context
o Context Map
3
107
@arafkarsh arafkarsh
Ubiquitous
Language
Vocabulary shared by
all involved parties
Used in all forms of spoken /
written communication
Ubiquitous
Language
Domain
Expert
Analyst Developers
QA
Design
Docs
Test Cases
Code
Restaurant Context – 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.
DDD: Ubiquitous Language: Strategic Design
108
As an Restaurant Owner
I want to know who my Customers are
So that I can serve them better
Role-Feature-Reason Matrix
BDD – Behavior Driven Development
Given Customer John Doe exists
When Customer orders food
Then
Assign customer preferences
as Veg or Non Veg customer
BDD Construct
@arafkarsh arafkarsh
Bounded Context – Strategic Design
109
• Bounded Context is a Specific Business Process / Concern.
• Components / Modules inside the Bounded Context are context specific.
• Multiple Bounded Contexts are linked using Context Mapping.
• One Team assigned to a Bounded Context.
• Each Bounded Context will have it’s own Source Code Repository.
• When the Bounded Context is being developed as a key strategic
initiative of your organization, it’s called the Core Domain.
• Within a Bounded Context the team must have same language called
Ubiquitous language for Spoken and for Design / Code Implementation.
@arafkarsh arafkarsh
DDD: App User’s Journey & Bounded Context
110
An e-Comm App User’s Journey can
run across multiple Bounded Context
/ Microservices.
User Journey X
Bounded
Context
Bounded
Context
Bounded
Context
User Journey Y
Bounded
Context
Bounded
Context
Bounded
Context
Product
Catalogue
Reviews
Product
Order Item
Shipping
Methods
Address
Payments
Order
Items
Category
Inventory
Event
Cart Items
Wish List Price Event
Category
Order
Added From
Cart
uses
uses
Understanding Bounded Context (DDD) of a e-Commerce App
Product
Context
Order
Context
Cart Context
Source: Domain-Driven Design
Reference by Eric Evans
Domain Driven Design
Product
Catalogue
Reviews
Product
Order Item
Shipping
Methods
Address
Payments
Order
Items
Category
Inventory
Event
Cart Items
Wish List Price Event
Category
Order
Added From
Cart
uses
uses
Can we carve out another Microservice from the
existing Microservices?
@arafkarsh arafkarsh
DDD: Bounded Context – Strategic Design
111
An App User’s Journey can run across
multiple Bounded Context / Micro
Services.
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
Prepared By
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
Prepared By
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
Areas of the domain treated
independently
Discovered as you assess
requirements and build language
Bounded
Context
Bounded
Context
Bounded
Context
User Journey X
@arafkarsh arafkarsh
DDD : Understanding Bounded Context
Source: Patterns, Principles and Practices of DDD – Page 124
This model shows multiple
responsibilities of the
shared Model – Product.
This is a classic example of
Big Ball of Mud.
112
@arafkarsh arafkarsh
DDD : Understanding Bounded Context
Source: Patterns, Principles and Practices of DDD – Page 127 Each of this context will become a Microservice
113
@arafkarsh arafkarsh
DDD : Understanding Bounded Context
Source: BoundedContext By Martin Fowler :
http://martinfowler.com/bliki/BoundedContext.html
• DDD deals with large models by
dividing them into different
Bounded Contexts and being explicit
about their interrelationships.
• Bounded Contexts have both
unrelated concepts
• Such as a support ticket only
existing in a customer support
context
• But also share concepts such as
products and customers.
• Different contexts may have
completely different models of
common concepts (Customer &
Product) with mechanisms to map
between these polysemic concepts
for integration.
114
@arafkarsh arafkarsh
Customer Model in Different Bounded Context
115
Order
Customer
• Customer ID
• Discount
• Bonus Program
Delivery
Customer
• Customer ID
• Address
• Preferred
Delivery method
• Packaging
• Delivery Contact
Billing
Customer
• Customer ID
• Billing Address
• Payment Type
• Tax
o Customer Model has different attributes in different contexts. So it avoids
storing all the customer info in one place and then sharing that across
multiple Bounded Contexts (Microservices).
o If you want to change Customer details related to Tax then only Billing
Bounded Context (Microservice) needs to be updated.
@arafkarsh arafkarsh
DDD : Understanding Bounded Context
Source: Patterns, Principles and Practices of DDD – Page 132
Each of this Bounded Context
will become a Microservice
Communication across Bounded Context
Source: Patterns, Principles and Practices of DDD – Page 203
116
@arafkarsh arafkarsh
DDD : Understanding Bounded Context
Source: Patterns, Principles and Practices of DDD – Page 157
Microservice is a Bounded Context
117
@arafkarsh arafkarsh
Bounded Context &
Hexagonal Architecture
• Ports & Adapters – Shopping Portal
118
@arafkarsh arafkarsh
Hexagonal Architecture
Ports & Adapters
The layer between the Adapter and
the Domain is identified as the Ports
layer. The Domain is inside the port,
and adapters for external entities are
outside the port.
The notion of a “port” invokes the
OS idea that any device that adheres
to a known protocol can be plugged
into a port. Similarly, many adapters
may use the Ports.
Source : http://alistair.cockburn.us/Hexagonal+architecture
https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net
Services
for UI
Ports
File
system Database
Order Tracking
JPA Repository
Implementation
Adapters
OrderProcessing
Domain Service
(Business Rules)
Implementation
Domain
Models
Domain Layer
Order Data
Validation
OrderService
REST Service
Implementation
OrderProcessing
Interface
p
Order Tracking
Repository
Interface
p
A
A
External
Apps
A
A A
Others
A
A
OrderService
Interface
p
Web
Services
External
Connectors
Business
Services
Data
Store
Use Case Boundary
Bounded Context
A
• Reduces Technical Debt
• Dependency Injection
• Auto Wiring
119
@arafkarsh arafkarsh
Specification Guidelines
• Approach to understanding
the Domain
• Discovering Bounded Context
120
@arafkarsh arafkarsh
Problem Space
121
Source: Patterns, Principles and Practices of DDD – Page xxxvi
@arafkarsh arafkarsh
How?
Focus on Core Complexity & Opportunity in
the Domain
Explore models in collaboration of Domain
Experts & Software Experts
Write software that expresses these
Models explicitly
Speak Ubiquitous Language within a
Bounded Context
122
Eric Evans – Explore DDD, Denver, 2017
@arafkarsh arafkarsh
Focus on
Clean
Boundaries
over
Perfect
Models
123
Source: Patterns, Principles and Practices of DDD – Page 38
@arafkarsh arafkarsh
How? Identity the areas of the business which is
critical for the success of the business.
Why are these areas important?
Why can't we buy a solution rather than
building it?
What makes the system worth building it?
Core Domain
124
Look at the Core Domain as a Product instead of a Project
@arafkarsh arafkarsh
How? Supporting Domains are the domains
that helps the Core Domain.
In an E-Commerce application like
Amazon or Flipkart, product search
functionality is a supporting domain.
Even off the shelf application can be
used in a supporting domain, For Ex.
Ticketing system.
Supporting
Domains
125
@arafkarsh arafkarsh
How? An Email Sending Service
Notification Services like, SMS,
Google Notifications (for
Android), iPhone Notifications.
Reporting & Dashboard
functionalities
Generic
Domains
126
@arafkarsh arafkarsh
Solution Space
127
Source: Patterns, Principles and Practices of DDD – Page xxxviI
@arafkarsh arafkarsh
Domain Vs. Domain Model
128
Source: Patterns, Principles and Practices of DDD – Page 43
o Analysis Model or
Business Model is to
describe the Problem
space / Domain.
o The Domain Model
contains only what is
relevant to solve the
problem.
o Domain Model MUST be
free of technical
complexities.
@arafkarsh arafkarsh
Domain Model
129
A domain Model is
not a particular
diagram; it is the
idea the diagram
intends to convey.
- Eric Evans
Domain Model: An
object of the Domain
that incorporates
both behaviour and
data.
- Martin Fowler
@arafkarsh arafkarsh
Indicators
for
Discovering
Bounded
Context
Identify the Business Capabilities from
the User Activities / Stories / Use
Cases
Based on Activities: If an area within the
system contains a set of exclusive activities
then that’s an indicator for a Business
Capabilities.
Based on Trigger: Any area which gets
automatically triggered based on external
input and does some activities based on that
trigger. Ex. Spam Checker, Virus Checker in
mail attachments.
130
@arafkarsh arafkarsh
Start with? User Journey / Use Cases / Scenarios
131
Source: Patterns, Principles and Practices of DDD – Chapter 2 – Page 16
@arafkarsh arafkarsh
List Core Activities
132
o List Code Activities for the
Primary Use Case
o Identify the Business Function
/ Capabilities of each of the
Activity
o Identify the User Role (Actor)
for this Activity,
o Ensure that the list of the
Activities complete the entire
Business Solution.
Activity Business
Function
Actor
1
2
3
4
5
6
7
8
9
10
@arafkarsh arafkarsh
Summary: User Journey / CCD / Domain Driven Design
133
User Journey
Bounded
Context
1
Bounded
Context
2
Bounded
Context
3
1. Bounded Contexts
2. Entity
3. Value Objects
4. Aggregate Roots
5. Domain Events
6. Repository
7. Service
8. Factory
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
Capability Centric Design
Domain Expert Analyst Architect QA
Design Docs Test Cases Code
Developers
Domain Driven Design
Ubiquitous Language
Core
Domain
Sub
Domain
Generic
Domain
@arafkarsh arafkarsh
DDD : Context Map
134
Source: Domain-Driven Design Reference by Eric Evans
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
@arafkarsh arafkarsh
DDD : Understanding Context Map
1. A context map provides Global View of the system that UML or architecture
diagrams completely miss, helping us to focus on choices that are really viable in
your scenario without wasting money.
2. Each Bounded Context fits within the Context Map to show how they should
communicate amongst each other and how data should be shared.
135
Up Stream (u) – Down Stream (d)
The upstream team may succeed independently of the
fate of the downstream team.
Mutually Dependent
Success depends on the success of both the teams.
Free
In which success or failure of the development work in
other contexts has little affect on delivery.
@arafkarsh arafkarsh
DDD: Context Map
136
Term Definition Action
Partnership When teams in two context will succeed or fail together, a
cooperative relationship often emerges.
Forge Partnerships
Shared Kernel Sharing a part of the Mode and associated code is very
intimate interdependency, which can leverage design work
or undermine it.
Keep the Kernel Small.
Customer /
Supplier
When two teams are in upstream – downstream
relationship, where the upstream team may succeed
independently of the fate of the downstream team, the
needs of the downstream come to be addressed in a
variety of ways with wide range of consequences.
Downstream priorities factor
into upstream planning.
Conformist Upstream has no motivation in this partnership to keep
the promise. Altruism may motivate Upstream developers
to give promises they cant keep.
Share just enough info with
upstream to keep their
motivation.
Anti
Corruption
Layer
When the translation between two bounded context
becomes more complex, then the translation layer takes
on a more defensive tone.
(down stream) creates a layer in
sync own model and matching
(up stream) functionality.
@arafkarsh arafkarsh
DDD: Context Map
137
Term Definition Action
Open Host
Service
When a subsystem has to be integrated with many others,
customizing a translator for each can bog down the team. There is
more and more to maintain, and more and more to worry about
when changes are made.
Use a one of
translator to augment
the Protocol to share
info (REST)
Published
Language
Translation between the models of two bounded contexts requires
a common language.
Published Language is often combined with Open Host Service.
Use a well
documented shared
language (JSON)
Separate Ways If two sets of functionality have no significant relationship, they
can be completely cut loose from each other. Integration is always
expensive and sometimes the benefit is small.
Bounded context with
no connection to
others.
Big Ball of
Mud
As we survey existing systems, we find that, in fact, there are parts
of systems, often large ones, where models are mixed and
boundaries are inconsistent.
Designate the mess as
a Big Ball of Mud.
@arafkarsh arafkarsh
Context Map – Coordination Efforts
138
Shared Bounded Context
Shared Kernel
Customer / Supplier
Published Language
Open Host Service
Anticorruption Layer
Conformist
Separate Ways
Coordination
Effort
@arafkarsh arafkarsh
DDD: Strategic Design Patterns
139
Pattern Description Page
1
Bounded
Context
They are
NOT
Modules
A Bounded Context delimits the applicability of a particular model so that the team
members have a clear and shared understanding of what has to be consistent and how it
relates to other Contexts. Contexts can be created from (but not limited to) the following:
• how teams are organized
• the structure and layout of the code base
• usage within a specific part of the domain
335
2 Context Map
Context mapping is a design process where the contact points and translations between
bounded contexts are explicitly mapped out. Focus on mapping the existing landscape,
and deal with the actual transformations later.
1. Shared Kernel
2. Customer / Supplier
3. Conformist
4. Anti Corruption Layer
5. Separate Ways
3
Specification
Pattern
Use the specification pattern when there is a need to model rules, validation and selection
criteria. The specification implementations test whether an object satisfies all the rules of
the specification.
4
Strategy
Pattern
The strategy pattern, also known as the Policy Pattern is used to make algorithms
interchangeable. In this pattern, the varying 'part' is factored out.
5
Composite
Pattern
This is a direct application of the GoF pattern within the domain being modeled. The
important point to remember is that the client code should only deal with the abstract
type representing the composite element.
Page Number from Domain Driven Design
– Published in 2015
@arafkarsh arafkarsh
Common Problems
140
1. Trying to make a perfect Boundary for the
Context.
2. Overemphasizing the importance of Tactical
Design Patterns
3. Using the same architecture for all Bounded
Contexts
4. Neglecting the Strategic Design Patterns
5. Focusing on Code rather than the principles of
DDD
@arafkarsh arafkarsh
Domain Driven Design
• Strategic Design
• Tactical Design
o Entity
o Value Object
o Aggregate Root
o Factory
o Repository
o Domain Service
o Domain Events
141
@arafkarsh arafkarsh
Domain Driven Design
142
Source: Domain-Driven Design Reference by Eric Evans
@arafkarsh arafkarsh
Layered Architecture
143
• Explicit Domain Models – Isolate your models from UI, Business
Logic.
• Domain Objects – Free of the Responsibility of displaying
themselves or storing themselves or managing App Tasks.
• Zero Dependency on Infrastructure, UI and Persistent Layers.
• Use Dependency Injection for Loosely Coupled Objects.
• All the Code for Domain Model in a Single Layer.
• Domain Model should be Rich enough to represent Business
Knowledge.
Source: DDD Reference by Chris Evans Page 17
@arafkarsh arafkarsh
Entity
144
Entities are Domain Concepts
with Identity and Continuity and
can be stored in a database.
Identity Examples of an Entity
• Order ID in Order Entity
• Social Security Number in
Person Entity
Entity
• Order (Aggregate Root)
• Order ID
• Order Item Array
• Payment
• Shipping Address
• Order Item
• Payment
• Total Payment
@arafkarsh arafkarsh
Value Objects
145
Value Object
• Shipping Address
• Name
• Street
• City
• State
• Country
• Item Value
• Amount
• Currency
• Audit Log
• Time
• User
• IP Address
It Represent a specific
business concept related
that Bounded Context.
Value objects doesn’t
have any specific identity.
It exists as part of an
Entity and stored along
with Entity.
• Currency
• USD
• INR
EURO
• POUND
• Order Status
• IN PROGRESS
• IN TRANSIT
• DELIVERED
• Payment Type
• CREDIT CARD
• DEBIT CARD
• Record State
Embeddable Object Enumeration
@arafkarsh arafkarsh
Understanding Aggregate Root
146
Order
Customer
Shipping
Address
Aggregate
Root
Line Item
Line Item
Line Item
*
Payment
Strategy
Credit Card
Cash
Bank Transfer
Source: Martin Fowler : Aggregate Root
• An aggregate will have one of its component
objects be the aggregate root. Any references
from outside the aggregate should only go to the
aggregate root. The root can thus ensure the
integrity of the aggregate as a whole.
• Aggregates are the basic element of transfer of
data storage - you request to load or save whole
aggregates. Transactions should not cross
aggregate boundaries.
• Aggregates are sometimes confused with
collection classes (lists, maps, etc.).
• Aggregates are domain concepts (order, clinic visit,
playlist), while collections are generic. An
aggregate will often contain multiple collections,
together with simple fields.
125
Domain
Driven
Design
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
@arafkarsh arafkarsh
Designing and Fine-Tuning Aggregate Root
147
Source : Effective Aggregate Design Part 1/2/3 : Vaughn Vernon
http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf
Aggregate Root - #1 Aggregate Root - #2
Super Dense Single Aggregate Root
Results in Transaction concurrency issues.
Super Dense Aggregate Root is split into 4
different smaller Aggregate Root in the 2nd
Iteration.
Working on different design models helps the developers to come up with best
possible design.
(C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
@arafkarsh arafkarsh
Rules for Building Aggregate Roots
1. Protect True Invariants in Consistency Boundaries. This rule has the
added implication that you should modify just one Aggregate instance in a single
transaction. In other words, when you are designing an Aggregate composition,
plan on that representing a transaction boundary.
2. Design Small Aggregates. The smallest Aggregate you can design is one with a
single Entity, which will serve as the Aggregate Root.
3. Reference Other Aggregates Only By Identity.
4. Use Eventual Consistency Outside the Consistency Boundary. This means that
ONLY ONE Aggregate instance will be required to be updated in a single
transaction. All other Aggregate instances that must be updated as a result of any
one Aggregate instance update can be updated within some time frame (using a
Domain Event). The business should determine the allowable time delay.
5. Build Unidirectional Relationship from the Aggregate Root.
148
@arafkarsh arafkarsh
Domain Services
149
Domain Services focuses bringing
the Behavior to your Domain
involving Entities and Value
Objects.
It focuses on a Single Responsibility.
Implementation of the Domain
Service resides in the service layer
(Adapters) and not in the Domain
Layer.
Domain Layer
• Models
• Repo
• Services
• Factories
Adapters
• Repo
• Services
• Web Services
Service Layer
@arafkarsh arafkarsh
Domain Events & Integration Events
150
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
Domain Layer
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
@arafkarsh arafkarsh
Communication Synchronous – RPC
151
Source: Patterns, Principles and Practices of DDD – Page 212
@arafkarsh arafkarsh
Communication Async – Event Based
152
Source: Patterns, Principles and Practices of DDD – Page 217
@arafkarsh arafkarsh
Reactive Programming Comparison : Iterable / Streams / Observable
153
First Class Visitor (Consumer)
Serial Operations
Parallel Streams (10x Speed)
Still On Next, On Complete and
On Error are Serial Operations
Completely Asynchronous
Operations
Java 8 – Blocking Call
Java 6 – Blocking Call Rx Java - Freedom
@arafkarsh arafkarsh
Reactive Programming RxJava Operator : Filter / Sort / FlatMap
154
Objective:
toSortedList() returns an Observable with a single List containing Fruits.
Using FlatMap to Transform Observable to Observable
Rx Example 2
@arafkarsh arafkarsh
Data Transfer Object vs. Value Object
155
Data Transfer Object Value Object
A DTO is just a data container which is used
to transport data between layers and tiers.
A Value Object represents itself a fix set of
data and is similar to a Java enum.
It mainly contains of attributes and it’s a
serializable object.
A Value Object doesn't have any identity, it is
entirely identified by its value and is
immutable.
DTOs are anemic in general and do not
contain any business logic.
A real world example would be Color.RED,
Color.BLUE, Currency.USD
Patterns of Enterprise Application Architecture : Martin Fowler
http://martinfowler.com/books/eaa.html
A small simple object, like money or a date range, whose equality isn’t based on identity.
486
P of EAA
Java EE 7 Retired the DTO
In Java EE the RS spec became the de-facto standard for remoting, so the implementation of
serializable interface is no more required. To transfer data between tiers in Java EE 7 you get the
following for FREE!
1. JAXB : Offer JSON / XML serialization for Free.
2. Java API for JSON Processing – Directly serialize part of the Objects into JSON
@arafkarsh arafkarsh
DTO – Data Transfer Object
• Security Considerations
• Data obtained from untrusted sources, such as user input from a Web page, should be cleansed and validated before
being placed into a DTO. Doing so enables you to consider the data in the DTO relatively safe, which simplifies future
interactions with the DTO.
156
The Problem Assembler Pattern
An object that carries data between processes in order to reduce the number of method calls.
Benefits
1. Reduced Number of Calls
2. Improved Performance
3. Hidden Internals
4. Discovery of Business
objects
Liabilities
1. Class Explosion
2. Additional Computation
3. Additional Coding Effort
https://msdn.microsoft.com/en-us/library/ms978717.aspx
Problem: How do you preserve the simple semantics of a procedure call interface without being
subject to the latency issues inherent in remote communication?
The Solution
401
P of EAA
@arafkarsh arafkarsh
DTO – Data Transfer Object
157
An object that carries data between processes in order to reduce the number of method calls.
The most misused pattern in the Java
Enterprise community is the DTO.
DTO was clearly defined as a solution for a
distribution problem.
DTO was meant to be a coarse-grained
data container which efficiently transports
data between processes (tiers).
On the other hand considering a dedicated
DTO layer as an investment, rarely pays off
and often lead to over engineered bloated
architecture.
Real World Java
EE Patterns
Adam Bien
http://realworldpatterns.com
Don't underestimate the cost of [using DTOs].... It's significant, and
it's painful - perhaps second only to the cost and pain of object-
relational mapping.
Another argument I've heard is using them in case you want to
distribute later. This kind of speculative distribution boundary is
what I rail against. Adding remote boundaries adds complexity.
One case where it is useful to use something like a DTO is when you
have a significant mismatch between the model in your presentation
layer and the underlying domain model.
In this case it makes sense to make presentation specific
facade/gateway that maps from the domain model and presents an
interface that's convenient for the presentation.
Patterns of Enterprise Application Architecture : Martin Fowler
http://martinfowler.com/books/eaa.html
401
P of EAA
@arafkarsh arafkarsh
Other subsystem
Anti-corruption layer 365
Domain
Driven
Design
Your subsystem
Anti Corruption Layer – ACL
158
@arafkarsh arafkarsh
Repository Pattern
• Objectives
• Use the Repository pattern to achieve one or more of the following
objectives:
• You want to maximize the amount of code that can be tested with
automation and to isolate the data layer to support unit testing.
• You access the data source from many locations and want to apply
centrally managed, consistent access rules and logic.
• You want to implement and centralize a caching strategy for the data
source.
• You want to improve the code's maintainability and readability by
separating business logic from data or service access logic.
• You want to use business entities that are strongly typed so that you
can identify problems at compile time instead of at run time.
• You want to associate a behavior with the related data. For example,
you want to calculate fields or enforce complex relationships or
business rules between the data elements within an entity.
• You want to apply a domain model to simplify complex business logic.
159
Repository Pattern Source:
Martin Fowler : http://martinfowler.com/eaaCatalog/repository.html | Microsoft : https://msdn.microsoft.com/en-us/library/ff649690.aspx
Mediates between the domain and data mapping layers using a collection-
like interface for accessing domain objects.
322
P of EAA
Conceptually, a Repository encapsulates the set of objects
persisted in a data store and the operations performed over them,
providing a more object-oriented view of the persistence layer.
Repository also supports the objective of achieving a clean
separation and one-way dependency between the domain and
data mapping layers.
@arafkarsh arafkarsh
Anemic Domain Model : Anti Pattern
• There are objects, many named after the nouns in
the domain space, and these objects are connected
with the rich relationships and structure that true
domain models have.
• The catch comes when you look at the behavior,
and you realize that there is hardly any behavior on
these objects, making them little more than bags of
getters and setters.
• The fundamental horror of this anti-pattern is that
it's so contrary to the basic idea of object-oriented
design; which is to combine data and process
together.
• The anemic domain model is really just a
procedural style design, exactly the kind of thing
that object bigots like me (and Eric) have been
fighting since our early days in Smalltalk.
160
Source: Anemic Domain Model By Martin Fowler :
http://martinfowler.com/bliki/AnemicDomainModel.html
• lockUser()
• unlockUser()
• addAddress(String address)
• removeAddress(String address)
@arafkarsh arafkarsh
Procedural Design Vs. Domain Driven Design
161
1. Anemic Entity Structure
2. Massive IF Statements
3. Entire Logic resides in Service
Layer
4. Type Dependent calculations are
done based on conditional checks
in Service Layer
4
1
2
3
Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html
Domain Driven Design with Java EE 6
By Adam Bien | Javaworld
@arafkarsh arafkarsh
Polymorphic Business Logic inside a Domain object
162
Domain Driven Design with Java EE 6
By Adam Bien | Javaworld
Computation of the total cost
realized inside a rich
Persistent Domain Object
(PDO) and not inside a service.
This simplifies creating very
complex business rules.
Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html
@arafkarsh arafkarsh
Type Specific Computation in a Sub Class
163
Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html
We can change the
computation of the shipping
cost of a Bulky Item without
touching the remaining
classes.
Its easy to introduce a new
Sub Class without affecting
the computation of the total
cost in the Load Class.
Domain Driven Design with Java EE 6
By Adam Bien | Javaworld
of
@arafkarsh arafkarsh
Object Construction : Procedural Way Vs. Builder Pattern
164
Procedural Way Builder Pattern
Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html
Domain Driven Design with Java EE 6
By Adam Bien | Javaworld
@arafkarsh arafkarsh
DDD: Tactical Design Patterns
165
Pattern Description Page
6 Entity An object defined Primarily by its identity is called an Entity 91
-
Value Object
(Already
referred in P of
EAA)
Many Objects have no conceptual Identity. These objects describe the
characteristic of a thing.
97
7
Aggregate
Aggregate is a cluster of domain objects that can be treated as a Single
Unit. Example Order and Order Item.
125
Aggregate Root
An Aggregate will have one of its component object be the Aggregate
Root.
127
-
Repositories
(Already
referred in P of
EAA)
A Repository represents all objects of a certain type as a conceptual set.
It acts like a collection, except with more elaborate querying capabilities.
Objects of appropriate type are added and removed, and the machinery
behind the Repository inserts them or deletes them from the database.
This definition gathers a cohesive set of responsibilities for providing
access to the roots of Aggregates from early life cycle through the end.
147
8
Factory /
Builder Pattern
When creation of an Object, or an entire Aggregate, becomes
complicated or reveals too much of the internal structure, Factories
provides encapsulation.
136
Page Number from Domain Driven Design
– Published in 2015
@arafkarsh arafkarsh
DDD: Tactical Design Patterns
166
Pattern Description Page
9
Factory / Builder
Pattern
When creation of an Object, or an entire Aggregate, becomes
complicated or reveals too much of the internal structure,
Factories provides encapsulation.
136
10 Domain Service
A Service tends to be named of an Activity rather than an Entity.
1. The Operation relates to a domain concept that is not a natural
part of an Entity.
2. The interface is defined in terms of other elements of the
Domain Model
3. The operation is stateless
104
11
Anti – Corruption
Layer
(External
Integration)
Creating an isolating layer to provide clients with functionality in
terms of their own Domain Model. The layer talks to the other
system through its existing interface, requiring little or no
modification to the other system. Internally the Layer translates in
both directions as necessary between the two models.
365
12 Domain Events
A Domain Event is a full-fledged part of the Domain Model, a
representation of of something that happened in the Domain.
Explicit events that the domain experts wants to track and
notified of or which are associated with the state changes in
other Domain Models.
Page Number from Domain Driven Design
– Published in 2015
@arafkarsh arafkarsh
Shopping Portal Modules – Code Packaging
167
Auth Products Cart Order
Customer
Domain Layer
• Models
• Repo
• Services
• Factories
Adapters
• Repo
• Services
• Web Services
Domain Layer
• Models
• Repo
• Services
• Factories
Adapters
• Repo
• Services
• Web Services
Domain Layer
• Models
• Repo
• Services
• Factories
Adapters
• Repo
• Services
• Web Services
Packaging Structure
Bounded Context
Implementation
(Repositories, Business Services, Web Services)
Domain Models
(Entities, Value Objects, DTOs)
(Repositories, Business Services, Web Services)
Entity Factories
Interfaces (Ports)
@arafkarsh arafkarsh
Shopping Portal Design based on Hexagonal Architecture
168
Monolithic App Design using DDD
Domain Driven Design helps you to migrate your monolithic App to Microservices based Apps
@arafkarsh arafkarsh
Shopping Portal
169
Order Context
Models
Value Object
• Shipping Address
• Currency
• Item Value
• Order Status
• Payment Type
• Record State
• Audit Log
Entity
• Order (Aggregate Root)
• Order Item
• Payment
DTO
• Order
• Order Item
• Shipping Address
• Payment
Domain Layer Adapters
• Order Repository
• Order Service
• Order Web Service
• Order Query Web Service
• Shipping Address Web Service
• Payment Web Service
Adapters Consists of Actual
Implementation of the Ports like
Database Access, Web Services
API etc.
Converters are used to convert
an Enum value to a proper
Integer value in the Database.
For Example, Order Status
Complete is mapped to integer
value 100 in the database.
Services / Ports
• Order Repository
• Order Service
• Order Web Service
Utils
• Order Factory
• Order Status Converter
• Record State Converter
• Order Query Web Service
• Shipping Address Web Service
• Payment Web Service
@arafkarsh arafkarsh
Summary: User Journey / CCD / Domain Driven Design
170
User Journey
Bounded
Context
1
Bounded
Context
2
Bounded
Context
3
1. Bounded Contexts
2. Entity
3. Value Objects
4. Aggregate Roots
5. Domain Events
6. Repository
7. Service
8. Factory
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
Capability Centric Design
Domain Expert Analyst Architect QA
Design Docs Test Cases Code
Developers
Domain Driven Design
Ubiquitous Language
Core
Domain
Sub
Domain
Generic
Domain
@arafkarsh arafkarsh
RESTful APIs
• Standards
• Api versioning standards
171
4
@arafkarsh arafkarsh
RESTful Guidelines
172
1. Endpoints as nouns, NOT verbs
Ex. /catalogues
/orders
/catalogues/products
and NOT
/getProducts/
/updateProducts/
2. Use plurals
Ex. /catalogues/{catalogueId}
and NOT
/catalogue/{catalogueId}
3. Documenting
4. Paging
5. Use SSL
6. HTTP Methods
GET / POST / PUT / DELETE / OPTIONS / HEAD
7. HTTP Status Codes (Effective usage)
8. Versioning
Media Type Version
GET /account/5555 HTTP/1.1
Accept: application/vnd.catalogues.v1+json
URL path version
https://domain/v1/catalogues/products
@arafkarsh arafkarsh
RESTful Guidelines – Query Examples
173
Search All
Products
Search Products By
Catalogue ID
Search Products By
Catalogue ID & Product ID
@arafkarsh arafkarsh
RESTful Guidelines – Query Examples
174
Two different
implementation
of same query
@arafkarsh arafkarsh 175
# Name * Who Uses Pros Cons
1
Media Type Versioning
Accept:
Application/vnd.api.article+xml;
version=1.0
Med GitHub
• Version Directly @
resource level
• Preserve URI
• Close to RESTful Specs
• Harder to Test
• Distort HTTP Headers purpose
• Tools required for testing
2
Custom Headers Versioning
X-API-Version: 2.
Med Microsoft • Preservers URI
• Harder to Test
• Tools required for testing
3
URI Versioning
api.example.com/v1/resource
High
Google
Twitter
Amazon
• Most common method
• Versions can be explored
using Browser
• Easy to use
• Disrupts RESTful Compliance.
URI should represent resource
and not versions
4
Domain Versioning
apiv1.example.com/resource
Low Facebook
• Same as are URI
Versioning
• Same as URI Versioning
5
Request Parameter
Versioning
GET /something/?version=0.1
High
Pivotal
NetFlix
• Similar to URI versioning • It can get messy
6
Date Versioning
First request saves the date.
Low Clearbit
• New APIs can be shipped
without changing the
end points
• Complex to implement
• Traceability is difficult.
API Versioning
@arafkarsh arafkarsh
Open API 3.0
176
@arafkarsh arafkarsh
Open API 3.0 - POM
177
Import Statements in your SpringBoot App
@arafkarsh arafkarsh
Open API 3.0
Setup in
Spring Boot
App
178
@arafkarsh arafkarsh
Open API 3.0
Setup in
Spring Boot
App
179
@arafkarsh arafkarsh
Open API 3.0
Setup in
Spring Boot
App
180
@arafkarsh arafkarsh
Open API 3.0
Documentation
Example
GET /
181
@arafkarsh arafkarsh
Open API 3.0
Documentation
Example
POST /
182
@arafkarsh arafkarsh
Open API 3.0
Documentation
Example
PUT /
183
@arafkarsh arafkarsh
Open API 3.0
Documentation
Example
DELETE /
184
@arafkarsh arafkarsh
Restful API Summary
185
o Endpoints as Nouns not VERBS
o /catalogues, /orders, /products/category
o API Versioning
o Use the best suited to your environment
o Use all the HTTP Verbs
o GET, POST, PUT, DELETE
@arafkarsh arafkarsh 186
100s Microservices
1,000s Releases / Day
10,000s Virtual Machines
100K+ User actions / Second
81 M Customers Globally
1 B Time series Metrics
10 B Hours of video streaming
every quarter
Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM
10s OPs Engineers
0 NOC
0 Data Centers
So what do NetFlix think about DevOps?
No DevOps
Don’t do lot of Process / Procedures
Freedom for Developers & be Accountable
Trust people you Hire
No Controls / Silos / Walls / Fences
Ownership – You Build it, You Run it.
@arafkarsh arafkarsh 187
50M Paid Subscribers
100M Active Users
60 Countries
Cross Functional Team
Full, End to End ownership of features
Autonomous
1000+ Microservices
Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf
1000+ Tech Employees
120+ Teams
@arafkarsh arafkarsh 188
Design Patterns are
solutions to general
problems that
software developers
faced during software
development.
Design Patterns
@arafkarsh arafkarsh 189
DREAM | AUTOMATE | EMPOWER
Araf Karsh Hamid :
India: +91.999.545.8627
http://www.slideshare.net/arafkarsh
https://www.linkedin.com/in/arafkarsh/
https://www.youtube.com/user/arafkarsh/playlists
http://www.arafkarsh.com/
@arafkarsh
arafkarsh
@arafkarsh arafkarsh 190
Source Code: https://github.com/MetaArivu Web Site: https://metarivu.com/ https://pyxida.cloud/
@arafkarsh arafkarsh 191
http://www.slideshare.net/arafkarsh
@arafkarsh arafkarsh
References
192
Design Thinking
1. What’s Design Thinking: 2020, Feb 4, https://www.youtube.com/watch?v=gHGN6hs2gZY
2. Design Thinking Process: 2017 Oct 23, https://www.youtube.com/watch?v=_r0VX-aU_T8
3. Design Thinking Workshop with Justin Ferrell of Stanford: 2013, Dec 20,
https://www.youtube.com/watch?v=Z4gAugRGpeY
Lean Startup
1. Lean Startup: Eric Ries, Talks @ Google: https://www.youtube.com/watch?v=fEvKo90qBns
2. Lean, Agile, Design Thinking: https://www.youtube.com/watch?v=OCL6RkUOShI
3. Jeff Gothelf : Lean vs Agile vs Design Thinking: https://www.youtube.com/watch?v=_4VPfmtwRac
4. Lean Startup Summary: Eric Ries, https://www.youtube.com/watch?v=RSaIOCHbuYw
@arafkarsh arafkarsh
References
193
1. July 15, 2015 – Agile is Dead : GoTo 2015 By Dave Thomas
2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google
3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head
4. Feb 17, 2019 - Lean vs Agile vs Design Thinking
5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban
6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained.
Agile Methodologies
@arafkarsh arafkarsh
References
194
1. Vmware: What is Cloud Architecture?
2. Redhat: What is Cloud Architecture?
3. Cloud Computing Architecture
4. Cloud Adoption Essentials:
5. Google: Hybrid and Multi Cloud
6. IBM: Hybrid Cloud Architecture Intro
7. IBM: Hybrid Cloud Architecture: Part 1
8. IBM: Hybrid Cloud Architecture: Part 2
9. Cloud Computing Basics: IaaS, PaaS, SaaS
1. IBM: IaaS Explained
2. IBM: PaaS Explained
3. IBM: SaaS Explained
4. IBM: FaaS Explained
5. IBM: What is Hypervisor?
Cloud Architecture
@arafkarsh arafkarsh
References
195
Microservices
1. Microservices Definition by Martin Fowler
2. When to use Microservices By Martin Fowler
3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler
4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern
5. Thought Works: Microservices in a Nutshell
6. Microservices Prerequisites
7. What do you mean by Event Driven?
8. Understanding Event Driven Design Patterns for Microservices
@arafkarsh arafkarsh
References – Microservices – Videos
196
1. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s
2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg
3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans
4. GOTO 2015 – Challenges Implementing Micro Services By Fred George
5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer
6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith
7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k
8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans
9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney
10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016
11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles
12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan
13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup.
14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant
15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula
16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford.
17. GOTO 2017 – Microservices without Servers. By Glynn Bird.
@arafkarsh arafkarsh
References
197
Domain Driven Design
1. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans
2. Mar 19, 2013 Domain Driven Design By Eric Evans
3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World
4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard
5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke
6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson
7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune
8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans
9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans
10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner
@arafkarsh arafkarsh
References
198
Event Sourcing and CQRS
1. IBM: Event Driven Architecture – Mar 21, 2021
2. Martin Fowler: Event Driven Architecture – GOTO 2017
3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016
4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young
5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS
6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler
7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes
@arafkarsh arafkarsh
References
199
Kafka
1. Understanding Kafka
2. Understanding RabbitMQ
3. IBM: Apache Kafka – Sept 18, 2020
4. Confluent: Apache Kafka Fundamentals – April 25, 2020
5. Confluent: How Kafka Works – Aug 25, 2020
6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020
7. Kafka Streams – Sept 4, 2021
8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018
9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019
@arafkarsh arafkarsh
References
200
Databases: Big Data / Cloud Databases
1. Google: How to Choose the right database?
2. AWS: Choosing the right Database
3. IBM: NoSQL Vs. SQL
4. A Guide to NoSQL Databases
5. How does NoSQL Databases Work?
6. What is Better? SQL or NoSQL?
7. What is DBaaS?
8. NoSQL Concepts
9. Key Value Databases
10. Document Databases
11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends
12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012
13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB
14. Oct 30, 2020 - Column vs Row Oriented Databases Explained
15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained!
1. Graph Databases
2. Column Databases
3. Row Vs. Column Oriented Databases
4. Database Indexing Explained
5. MongoDB Indexing
6. AWS: DynamoDB Global Indexing
7. AWS: DynamoDB Local Indexing
8. Google Cloud Spanner
9. AWS: DynamoDB Design Patterns
10. Cloud Provider Database Comparisons
11. CockroachDB: When to use a Cloud DB?
@arafkarsh arafkarsh
References
201
Docker / Kubernetes / Istio
1. IBM: Virtual Machines and Containers
2. IBM: What is a Hypervisor?
3. IBM: Docker Vs. Kubernetes
4. IBM: Containerization Explained
5. IBM: Kubernetes Explained
6. IBM: Kubernetes Ingress in 5 Minutes
7. Microsoft: How Service Mesh works in Kubernetes
8. IBM: Istio Service Mesh Explained
9. IBM: Kubernetes and OpenShift
10. IBM: Kubernetes Operators
11. 10 Consideration for Kubernetes Deployments
Istio – Metrics
1. Istio – Metrics
2. Monitoring Istio Mesh with Grafana
3. Visualize your Istio Service Mesh
4. Security and Monitoring with Istio
5. Observing Services using Prometheus, Grafana, Kiali
6. Istio Cookbook: Kiali Recipe
7. Kubernetes: Open Telemetry
8. Open Telemetry
9. How Prometheus works
10. IBM: Observability vs. Monitoring
@arafkarsh arafkarsh
References
202
1. Feb 6, 2020 – An introduction to TDD
2. Aug 14, 2019 – Component Software Testing
3. May 30, 2020 – What is Component Testing?
4. Apr 23, 2013 – Component Test By Martin Fowler
5. Jan 12, 2011 – Contract Testing By Martin Fowler
6. Jan 16, 2018 – Integration Testing By Martin Fowler
7. Testing Strategies in Microservices Architecture
8. Practical Test Pyramid By Ham Vocke
Testing – TDD / BDD
@arafkarsh arafkarsh 203
1. Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and
most of the important components are plug- gable.
2. Pumba : A chaos testing and network emulation tool for Docker.
3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH-
managed environment, as an aid to resilience testing of high-availability systems.
4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours.
5. Blockade : Docker-based utility for testing network failures and partitions in distributed
applications.
6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server.
7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an
OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift
components like Pods or Deployment Configs and randomly terminates them.
8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS
deployed to an Azure Resource Manager-based resource group.
9. Tugbot : Testing in Production (TiP) framework for Docker.
Testing tools
@arafkarsh arafkarsh
References
204
CI / CD
1. What is Continuous Integration?
2. What is Continuous Delivery?
3. CI / CD Pipeline
4. What is CI / CD Pipeline?
5. CI / CD Explained
6. CI / CD Pipeline using Java Example Part 1
7. CI / CD Pipeline using Ansible Part 2
8. Declarative Pipeline vs Scripted Pipeline
9. Complete Jenkins Pipeline Tutorial
10. Common Pipeline Mistakes
11. CI / CD for a Docker Application
@arafkarsh arafkarsh
References
205
DevOps
1. IBM: What is DevOps?
2. IBM: Cloud Native DevOps Explained
3. IBM: Application Transformation
4. IBM: Virtualization Explained
5. What is DevOps? Easy Way
6. DevOps?! How to become a DevOps Engineer???
7. Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg
8. NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM
9. DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk
10. SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE
11. DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU
12. SRE @ Google: https://www.youtube.com/watch?v=d2wn_E1jxn4
@arafkarsh arafkarsh
References
206
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. Zuul Edge Server, Ketan Gote, May 22, 2017
10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017
11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017
12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017
13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016
14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016
15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015
@arafkarsh arafkarsh
References
207
16. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx
17. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
18. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/
19. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs
20. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer
21. CQS : http://en.wikipedia.org/wiki/Command–query_separation
22. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem
23. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
24. CAP 12 years how the rules have changed
25. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices
26. Pat Helland (Amazon) : Life beyond distributed transactions
27. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw
28. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem
29. Rx Observable : https://dzone.com/articles/using-rx-java-observable