Agile, User Stories, Domain Driven Design

@arafkarsh arafkarsh
ARAF KARSH HAMID
Co-Founder / CTO
MetaMagic Global Inc., NJ, USA
@arafkarsh
arafkarsh
Microservice
Architecture Series
Building Cloud Native Apps
Design Thinking / Lean / Agile
Architecture Styles
Domain Driven Design
RESTful / Open API 3.0
Part 1 of 11

@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

Agile
Scrum (4-6 Weeks)
Developer Journey
Monolithic
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
Scrum / Kanban (1-5 Days)
Mandatory
Design
Patterns
Infrastructure Design Patterns
CI
DevOps
Event Streaming / Replicated Logs
SQL NoSQL
CD
Container Orchestrator Service Mesh

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.

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

Three Mindsets of Product Development
Design
Thinking Lean Agile
Source: Jonny Schneider, Thought Works
Explore the
Problem
Build the
right things
Build the
things right
0
6

Design Thinking
8

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
Tom Klinkowstein – Professor of Design & New Media, New York
9

Three Mindsets of Product Development
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
10

Design
Thinking
Empathize
Define
Ideate
Prototype
Test
Ideate
Build
Product
Measure
Data
Learn
Lean
Design Thinking / Lean Startup
11

Design Thinking / Lean / Agile
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
12

CAPABILITY CENTRIC DESIGN
• Business Functions
• Business process
• Team structure
13
1

From Object Modeling to Process Modeling
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
14

Business Solution & Business Process
 Business Solution focuses the entire Journey of the
User which can run across multiple Microservices.
 Business Solution comprises a set of Business
Processes.
 A specific Microservice functionality will be focused
on a Business Process / Concern
 Business Process can be divided further into
Business Functions
15

Business Solution & Business Process
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
16

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
Front-End-Team Back-End-Team Database-Team
In a typical Monolithic way the team is
divided based on technology / skill set
rather than business functions. This leads
to not only bottlenecks but also lack of
understanding of the Business Domain.
QA Team
QA = Quality Assurance
PO = Product Owner
Vertically sliced Product Team
Front-End
Back-End
Database
Business
Capability 1
QA
Team
PO
Front-End
Back-End
Database
Business
Capability 2
QA
Team
PO
Front-End
Back-End
Database
Business
Capability n
QA
Team
PO
17

From
Project Based
Activity
Oriented
To
Product Based
Outcome
Oriented
Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html
18

User Stories
• User Stories
• Behavior Driven Design
• Writing Good Stories
• Estimate and Planning
• Case Study
Theme Epic User Story Sprint
19

User Story
20
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

Acceptance Criteria / Behavior Driven Development
21
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 Developer builds software based on Specific
Usage scenarios with respect to the Use Case
Tester Tester builds test cased based on Use Case
Scenarios and finds issues.
The Gaps identified in this
process is filled up by
linking the User Stories
with Acceptance Criteria.

INVEST in Good Stories
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.
22

3 C’s of User Stories
Card Conversation Confirmation
A Story card
provides the written
description of the
Story. It helps in
planning and
estimation.
Conversation is the
discussion between
Product Owners, Users,
and the Engineering
team to bring in the
clarity in the stories.
These are the
Acceptance Criteria
which needs to be
satisfied to ensure
that the story meets
all the requirements.
23

User Stories – Small Stories
• 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 few hours to 1-2
Person days.
• Each story can have 3-7 Acceptance criteria.
• Spring backlog will be having 6-10 stories.
• If a story survives more than 1 sprint, then the story
needs to broken down to smaller stories.
Source: User Story A Pragmatic View, Page 78-80. Published 0ct 19, 2019
24

Features of BDD
25
• 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.

User Story / Behavior Driven Development
26
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
When
he buys products ABC for $1000
USD
Then He becomes a Gold Customer
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
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

Estimate – Story Points / Velocity
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.
27

Planning – MoSCoW Rules
Priority
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
28

Story Anti-Patterns
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
29

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.
30

User Stories – Case Study
• Minimum Viable Product
• Case Study – eCommerce Application – ShopEasy
• User Journey and Story Map
31

What exactly
is a
Minimum
Viable
Product
Let us understand this with a case study on eCommerce Shopping Portal.
32

ShopEasy – eCommerce Portal
Theme Epic User Story Sprint
ShopEasy – eCommerce Application
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
33

User Journey with Story Map
Global Search
Search by Brand
Search by Price
Search by Model
Search by Rating
Product Details
Image Gallery
Product Reviews
User Shopping Experience
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
34

User Journey with Story Map & Release Cycles
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
35

Shopping Portal – Architects View
User Journey
36

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
37

Shopping Portal
/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 Pod
Payment
Service
N4
N3
N1
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)
38

Stories – Customer Registration
User Journey
39

Epic – Customer
As a Consumer
I want to register eCommerce Portal
So that I can buy products
User Story – 1 : Registration
BDD Acceptance Criteria – 1: Save User
Given The fields First Name, Last Name, DOB
Address, Email Address, Phone No.
When User enters values in the fields First
Name, Last Name, DOB Address, Email
Address, Phone No.
Then If the following fields contains values
First Name, Last Name, Address, Email
Address and Phone No.
AND Age is greater than 18
Save the Data.
BDD Acceptance Criteria – 2 : Generate Password
Given User Info Available
When Email Address is a valid email
Then Generate the password
AND Send mail with user email address as
login id the URL of the portal
AND Send Password in a separate email
address.
AND Store data on mail status as mail send
or failed.
BDD Acceptance Criteria – 3 : Resend Mail
Given User Registration mail status is available
When The Mail status is failed.
Then Send the mail again
AND stored the attempt number.
40

Epic – Customer
As a Consumer
I want to login to eCommerce Portal
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 User enters login id and clicks the continue
button, the page shows the password page.
AND the the user enters password and
clicks 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 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
41

Stories – Shopping : Sprint R1
User Journey
42

Epic – Product Search
As a Consumer
I want to search for a product
User Story – 1 : Global Search
BDD Acceptance Criteria – 1 : Global Search
Given The user logged into the portal and product
search page is 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
service returns the result which contains
following fields for all the records: Product
Name, Product Model, Price, Description,
Product Image
Else returns zero record.
BDD Acceptance Criteria – 2 : Global Search
Given 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
service returns the result which contains
following fields for all the records: Product
Name, Product Model, Price, Description,
Product Image
43

Epic – Product Page
As a Consumer
I want to check a Product
So that I can buy the product
User Story – 1 : Show Product
BDD Acceptance Criteria – 1: Show Product
Given The user logged into the portal and a product is
searched and results are available
When The user then clicks a product for product details
Then The system will show that product details based
on the product ID with the 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 error “Selected Product details are not
available”.
BDD Acceptance Criteria – 2: Retrieve Product
When The Input contains product id
Then The system will return that 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 error “Selected Product
details not available”.
Do you want to use HATEOAS with REST?
44

Epic – Shopping Cart
As a Consumer
I want to Add a Product to Cart
User Story – 1 : Add to Cart
BDD Acceptance Criteria – 1: Add to Cart
Given The user logged into the portal and 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) into the
card and Updates 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
When The Input contains user login id, product
id
Then The system will add the Item (Product)
into the card Saves the Cart information
in the DB
AND if the save fails the system shows
an Error “Unable to Add Product to the
Cart”.
45

As a Consumer
I want to see all the items in the Cart
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 with 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 a message “Cart is
Empty”
BDD Acceptance Criteria – 2: Show Cart
When The Input contains user login id
Then The system retrieves all the Cart Items
from the DB and shows in the UI with 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 a
message “Cart is Empty
46

As a Consumer
I want to Delete a Product from the Cart
So that I can buy other items in the cart.
User Story – 3 : Delete from Cart
BDD Acceptance Criteria – 1: Delete From Cart
Given The user logged into the portal and clicked the
Shopping Cart, and the cart displays all the item
When The user then clicks Delete Button for a Product
Then The system will delete the Item (Product) from
the cart and Updates Item counter in the Cart
Icon
AND deletes 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
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”.
47

Epic – Customer
As a Consumer
I want to Select Shipping Address
So that I can ship the items to that Address
User Story – 3 : Select Address BDD Acceptance Criteria – 1 : Show Address
Given The user in the Shopping Cart Page
When User Clicks Proceed to Buy Button
Then The System shows the Available Address for
Shipping
BDD Acceptance Criteria – 2 : Select Address
Given The user in the Shopping Cart Page with
Available Shipping Address
When User Selects Address and Clicks Proceed to
Buy
Then The System save the Temp Order details
from Items from Shopping and Selected
Shipping Address
AND this 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
When Input contains user login id, items, shipping
address
Then The System save the Temp Order details
from Items from Shopping and Selected
Shipping Address
AND this details are valid only for the user
session. If the order is not placed Temp
Order items will be put back in Cart DB
48

Epic – Order
As a Consumer
I want to Process the Order
User Story – 1 : Process Order
BDD Acceptance Criteria – 1 : Add Payment
Given The user in the Order Cart Page with Items and
selected Shipping Address
When User Selects Payment Option As Credit Card
AND Input the Credit Card Details in the following
fields Card Name, Card No. Expiry Date, CVV
Number
Then The System Validates the Credit Card Number and
the Expiry Date and Card Name & CVV Must NOT be
Null
IF Invalid Systems says invalid Payment details else
Saves the info and proceed for payment.
BDD Acceptance Criteria – 3 : Save Payment
When Input contains user login id, order id, payment
details (card number only last 4 digits)
Then The System Validates the Credit Card Number
and the Expiry Date and Card Name and CVV
Must NOT be Null
IF Invalid Systems returns invalid Payment
details
ELSE
Saves the following info Card Name, Card
Number (only last 4 digits), Expiry Date
BDD Acceptance Criteria – 3 : Payment Gateway
When Input contains Valid payment details
Then With the Valid Payment Details System calls
External Payment Service for Payment
Processing and Returns Result to Calling System
49

Epic – Payment
As a Consumer
I want to Make Payment
User Story – 1 : Make Payment
BDD Acceptance Criteria – 1 : Process OTP
Given User Entered the Payment Details and
Clicked Proceed to Buy and the System
shows the Payment Service Page
When User Enters One Time Password (OTP) and
clicks Proceed
Then The System Sends the OTP to the External
Payment Gateway and the result is return to
the Caller.
BDD Acceptance Criteria – 2 : Order Status
When Input contains Payment Status.
Then If the payment is successful, the Order
Status is changed to Successful Else the
items are returned to the Card
50

Stories – Shopping : Sprint R2
User Journey
51

Epic – Customer
As a Consumer
I want to Reset the Password
So that I can login to Portal
User Story – 3 : Forgot Password
BDD Acceptance Criteria – 1 : Forgot Password
When The Input contains 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
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
When The user clicks Forgot Password then the
pages shows Forgot Password Page,
AND the user enters Email Address and click
the continue button
AND then the page goes to 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
AND send the new password in an email to
the user.
AND Stores the status of email delivery.
52

Epic – Product Search
As a Consumer
I want to search for a product within a price range
User Story – 2 : Search By Price Range
BDD Acceptance Criteria – 1: By Price Range
Given The user logged into the portal and product
search page is 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 service returns the result which contains
following fields for all the records: Product Name,
Product Model, Price, Description, Product Image
BDD Acceptance Criteria – 2: By Price Range
When The Input contains 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 service returns
the result which contains following fields
for all the records: Product Name,
Product Model, Price, Description,
Product Image
53

Epic – Product Page
As a Consumer
I want to check a Product
User Story – 2 : Show Product with Image Gallery
BDD Acceptance Criteria – 1: Show Product
Given The user logged into the portal and a product is
searched and results are available
When The user then clicks a product for product details
Then The system will show that product details based
on the product ID with the following details.
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 error
“Selected Product details are not available”.
BDD Acceptance Criteria – 2: Retrieve Product
When The Input contains product id
Then The system will return that product
details based on the product ID with the
following details.
Product Name, Product Rating, Price,
Product Description and Image Gallery
If the product is not available, then the
system will show error
“Selected Product details not available”.
Do you want to use HATEOAS with REST?
54

As a Consumer
I want to Update Quantity of a Product in the Cart
User Story – 3 : Update the Cart
BDD Acceptance Criteria – 1: Update Quantity
Given The user logged into the portal and clicked the
Shopping Cart, and the cart displays all the item
When The user then input 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
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”
55

Epic – Order
As a Consumer
I want to Process the Order
User Story – 1 : Process Order
BDD Acceptance Criteria – 1 : Add Payment
Given The user in the Order Cart Page with Items
and selected Shipping Address
When User Selects Payment Option As Credit Card
and PayPal
AND Input the PayPal Details
Then The System Validates the PayPal Details
IF Invalid Systems says invalid Payment
details else
Saves the info and proceed for payment.
BDD Acceptance Criteria – 3 : Save Payment
When Input contains user login id, order id,
payment details (PayPal Details
Then The System Validates the PayPal Details
IF Invalid Systems returns invalid Payment
details
ELSE
Saves the PayPal Details for Transaction
BDD Acceptance Criteria – 3 : Payment Gateway
When Input contains Valid payment details
Then With the Valid Payment Details System calls
External Payment Service for Payment
Processing and Returns Result to Calling
System
56

User Journey / Story Map & Release Cycles
Customer
View Product
Search
User Journey
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
Kanban Cycle: Each of the Story can be released without waiting for other stories to be completed resulting
in Shorter Releases as all the stories are independent!
57

Capability Centric Design Summary
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
58

Agile
• Agile Values
• Scrum
• Scrum Rules
• Kanban Boards and cards
• Kanban vs Scrum
• Benefits of kanban
59

Agile Values
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
60

Scrum
4 – 8 People
Complete
Specs
Stories
Planned
for a
Sprint
Max
8 Hours
Max
15 Mins
Multiple
increments
within a
Sprint
1 Month
Release
61

Scrum Events
All the work necessary to achieve the Product Goal, including Sprint
Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within
Sprints
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 purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt
the Sprint Backlog as necessary, adjusting the upcoming planned work.
SPRINT REVIEW
The purpose of the Sprint Review is to inspect the outcome of the Sprint and
determine future adaptations. The Scrum Team presents the results of their work
to key stakeholders and progress toward the Product Goal is discussed.
SPRINT
RETROSPECTIVE
The purpose of the Sprint Retrospective is to plan ways to increase quality and
effectiveness
62

Scrum Artifacts
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
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
63

Sprint
Backlog
64

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.
65

Scrum Values
66

What is Kanban
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.
67

Kanban History
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.
68

Three Principles of Kanban
69
Source: https://resources.collab.net/agile-101/what-is-kanban
• Visualize what you do today
(workflow): seeing all the items in
context of each other can be very
informative
• Limit the amount of work in progress
(WIP): this helps balance the flow-
based approach, so teams don’t start
and commit to too much work at once
• Enhance flow: when something is
finished, the next highest thing from
the backlog is pulled into play

Kanban Board
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
to tasks and each Task should
NOT take more than 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.
70

6 Core Practices in Kanban
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/
71

Release Cycles
72
Kanban
Preparation
Requirements
Design
Development
Testing
Release
1 – 4 Weeks Cycle
Scrum
1 Month (Max) Cycle
1 or 2 Weeks Cycle
also allowed

Similarities between Kanban and Scrum
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.
73

Kanban vs. Scrum
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/
74

Benefits of Kanban
• 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
75

Agile is
not
what
you do.
Agility is
how
you do
it.
76

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
2
77

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 78

Component Based Architecture
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).
79

Layered Architecture Style
UI Layer
WS
BL
DL
Database
Shopping
Cart
Order
Customer
Inventory
It was developed by John J. Donovan in Open Environment Corporation (OEC), a tools
company he founded in Cambridge, Massachusetts.
3 Tier Architecture Pattern
o All the 3 Layers are
separated by network and
data is transferred by Value.
o You can upgrade a layer
without worrying about
impact on the other layer as
long as contract between
the layers are intact.
o Logic Tier can be further
divided into
1. Web Services Layer
2. Business Layer
3. Database Layer
https://professordonovan.com/open-environment-corporation
80

Service Based Architecture
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 are based on XML, JSON, ProtoBuf etc. Contract versioning is key
aspect of the contracts and its future evolution.
4. Availability and Responsiveness: Availability ensures that there are no single point of
failures and Responsiveness to ensure that the Service Respond in a timely manner.
5. Security: As Services are independent components, it’s important that security and
access controls are taken care off. 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 are patterns focusing on addressing these
challenges.
81

SOA – Service Oriented Architecture
UI Layer
Database
Shopping
Cart
Order
Customer
Inventory
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
82

Micro Kernel Architecture Pattern
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
1. extensibility,
2. flexibility, and
3. isolation of application features
4. and custom processing logic
Source: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html
83

DDD: Bounded Context – Strategic Design
84
• 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.

DDD: App User’s Journey & Bounded Context
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
Product
Catalogue
Reviews
Product
Order Item
Shipping
Methods
Address
Payments
Order
Items
Category
Inventory
Event
Cart Items
Category
Order
Added From
Cart
uses
uses
Can we carve out another Microservice from the
existing Microservices?
85

Domain Driven Design – Tactical Design
86
Source: Domain-Driven Design Reference by Eric Evans

DDD: Understanding Aggregate Root
87
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

Event Sourcing Intro
88
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
2
Events
1. Profile Created Event
2. Title Updated Event
3. Address Added Event
4. Notes Deleted Event
3
Profile
Address
New Title
Current State of the
Customer Profile
4
Event store
Single Source of Truth
Greg
Young

Event Sourcing & CQRS (Command and Query Responsibility Segregation)
• In traditional data management systems, both
commands (updates to the data) and queries
(requests for data) are executed against the
same set of entities in a single data repository.
• CQRS is a pattern that segregates the
operations that read data (Queries) from the
operations that update data (Commands) by
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.
89
MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx |
Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html
CQS :
Bertrand Meyer
Axon
Framework
For Java
Java Axon Framework Resource : http://www.axonframework.org
Greg
Young

Distributed Tx: SAGA Design Pattern instead of 2PC
90
Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying
the termination of shorter and more common transactions.
Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem,
Dept. of Computer Science, Princeton University, NJ, USA
T1 T2 Tn
Local Transactions
C1 C2 Cn-1
Compensating Transaction
Divide long–lived, distributed transactions into quick local ones with compensating actions for
recovery.
Travel : Flight Ticket & Hotel Booking Example
BASE (Basic Availability, Soft
State, Eventual Consistency)
Room Reserved
T1
Room Payment
T2
Seat Reserved
T3
Ticket Payment
T4
Cancelled Room Reservation
C1
Cancelled Room Payment
C2
Cancelled Ticket Reservation
C3

API Architecture Maturity Levels
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/
•
91

Architecture Styles Summary
92
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

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

• Strategic Design
• Tactical Design
o Ubiquitous Language
o Bounded Context
o Context Map
3
94

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
As an Restaurant Owner
I want to know who my Customers are
So that I can serve them better
BDD – Behavior Driven Development
When Customer orders food
Then
Assign customer preferences
as Veg or Non Veg customer
BDD Construct
95

Bounded Context – Strategic Design
• 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.
96

DDD: App User’s Journey & Bounded Context
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
Category
Order
Added From
Cart
uses
uses
Understanding
Bounded
Context
(DDD)
of
a
e-Commerce
App
Product
Context
Order
Context
Cart Context
Product
Catalogue
Reviews
Product
Order Item
Shipping
Methods
Address
Payments
Order
Items
Category
Inventory
Event
Cart Items
Category
Order
Added From
Cart
uses
uses
Can we carve out another Microservice from the
existing Microservices?
97

DDD: Bounded Context – Strategic Design
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
Menu
uses
uses
Dinning
Order
Reservation
Tables
Recipes
Raw
Materials
Frozen
Semi Cooked
Appetizer Veg
Appetizer Non
Veg
Soft Drinks
Main Course
Non Veg
Main Course
Veg
Hot Drinks Desserts
Steward
Chef
Menu
uses
uses
Understanding
Bounded
Context
(DDD)
of
a
Restaurant
App
Dinning
Context
Kitchen
Context
Menu Context
Areas of the domain treated
independently
Discovered as you assess
requirements and build language
Bounded
Context
Bounded
Context
Bounded
Context
User Journey X
98

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.
99

Source: Patterns, Principles and Practices of DDD – Page 127 Each of this context will become a Microservice
100

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.
101

Customer Model in Different Bounded Context
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.
102

Each of this Bounded Context
will become a Microservice
Communication across Bounded Context
103

Microservice is a Bounded Context
104

Bounded Context &
Hexagonal Architecture
• Ports & Adapters – Shopping Portal
105

Hexagonal Architecture
Ports & Adapters
The layer between the Adapter and
the Domain is identified as the Ports
layer. The Domain is inside the port,
adapters for external entities are on
the outside of 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
Data
Store
Use Case Boundary
Bounded Context
A
• Reduces Technical Debt
• Dependency Injection
• Auto Wiring
106

Specification Guidelines
• Approach to understanding
the Domain
• Discovering Bounded Context
107

Problem Space
Source: Patterns, Principles and Practices of DDD – Page xxxvi
108

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
Eric Evans – Explore DDD, Denver, 2017
109

Focus on
Clean
Boundaries
over
Perfect
Models
110

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
Look at the Core Domain as a Product instead of a Project
111

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
112

How? An Email Sending Service
Notification Services like, SMS,
Google Notifications (for
Android), iPhone Notifications.
Reporting & Dashboard
functionalities
Generic
Domains
113

Solution Space
Source: Patterns, Principles and Practices of DDD – Page xxxviI
114

Domain Vs. Domain Model
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.
115

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.
116

Start with? User Journey / Use Cases / Scenarios
Source: Patterns, Principles and Practices of DDD – Chapter 2 – Page 16
117

List Core Activities
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
118

Summary: User Journey / CCD / Domain Driven Design
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
Domain Expert Analyst Architect QA
Design Docs Test Cases Code
Developers
Ubiquitous Language
Core
Domain
Sub
Domain
Generic
Domain
119

DDD : Context Map
120

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.
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.
121

DDD: Context Map
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.
122

DDD: Context Map
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.
123

Context Map – Coordination Efforts
Shared Bounded Context
Shared Kernel
Customer / Supplier
Published Language
Open Host Service
Anticorruption Layer
Conformist
Separate Ways
Coordination
Effort
124

DDD: Strategic Design Patterns
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
125

Common Problems
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
126

• Strategic Design
• Tactical Design
o Entity
o Value Object
o Aggregate Root
o Factory
o Repository
o Domain Service
o Domain Events
127

128

Layered Architecture
• 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
129

Entity
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
130

Value Objects
Value Object
• 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
131

Understanding Aggregate Root
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
132

Designing and Fine-Tuning Aggregate Root
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.
133

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.
134

Domain Services
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
135

Domain Events & Integration Events
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
136

Communication Synchronous – RPC
137

Communication Async – Event Based
138

Reactive Programming Comparison : Iterable / Streams / Observable
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
139

Reactive Programming RxJava Operator : Filter / Sort / FlatMap
Objective:
toSortedList() returns an Observable with a single List containing Fruits.
Using FlatMap to Transform Observable <List> to Observable <Fruit>
Rx Example 2
140

Data Transfer Object vs. Value Object
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
141

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.
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
142

DTO – Data Transfer Object
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
143

Other subsystem
Anti-corruption layer 365
Domain
Driven
Design
Your subsystem
Anti Corruption Layer – ACL
144

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.
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.
145

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.
Source: Anemic Domain Model By Martin Fowler :
http://martinfowler.com/bliki/AnemicDomainModel.html
• lockUser()
• unlockUser()
• addAddress(String address)
• removeAddress(String address)
146

Procedural Design Vs. Domain Driven Design
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
147

Polymorphic Business Logic inside a Domain object
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.
148

Type Specific Computation in a Sub Class
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.
of
149

Object Construction : Procedural Way Vs. Builder Pattern
Procedural Way Builder Pattern
150

DDD: Tactical Design Patterns
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
151

DDD: Tactical Design Patterns
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.
152

Shopping Portal Modules – Code Packaging
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)
153

Shopping Portal Design based on Hexagonal Architecture
Monolithic App Design using DDD
Domain Driven Design helps you to migrate your monolithic App to Microservices based Apps
154

Shopping Portal
Order Context
Models
Value Object
• Currency
• Item Value
• Order Status
• Payment Type
• Record State
• Audit Log
Entity
• Order (Aggregate Root)
• Order Item
• Payment
DTO
• Order
• Order Item
• 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
155

Summary: User Journey / CCD / Domain Driven Design
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
Domain Expert Analyst Architect QA
Design Docs Test Cases Code
Developers
Ubiquitous Language
Core
Domain
Sub
Domain
Generic
Domain
156

RESTful APIs
• Standards
• Api versioning standards
157
4

RESTful Guidelines
158
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

RESTful Guidelines – Query Examples
159
Search All
Products
Search Products By
Catalogue ID
Search Products By
Catalogue ID & Product ID

RESTful Guidelines – Query Examples
160
Two different
implementation
of same query

# 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

Open API 3.0
162

Open API 3.0 - POM
163
Import Statements in your SpringBoot App

Open API 3.0
Setup in
Spring Boot
App
164

Open API 3.0
Setup in
Spring Boot
App
165

Open API 3.0
Setup in
Spring Boot
App
166

Open API 3.0
Documentation
Example
GET /
167

Open API 3.0
Documentation
Example
POST /
168

Open API 3.0
Documentation
Example
PUT /
169

Open API 3.0
Documentation
Example
DELETE /
170

Restful API Summary
171
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

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.

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

Design Patterns are
solutions to general
problems that
software developers
faced during software
development.
Design Patterns

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

Source Code: https://github.com/MetaArivu Web Site: https://metarivu.com/ https://pyxida.cloud/

http://www.slideshare.net/arafkarsh

References
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
178

References
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
179
1. IBM: IaaS Explained
2. IBM: PaaS Explained
3. IBM: SaaS Explained
4. IBM: FaaS Explained
5. IBM: What is Hypervisor?
Cloud Architecture

References
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
180

References – Microservices – Videos
181
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.

References
182
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

References
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
183

Agile, User Stories, Domain Driven Design

Agile, User Stories, Domain Driven Design

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Agile, User Stories, Domain Driven Design

Similaire à Agile, User Stories, Domain Driven Design (20)

Plus de Araf Karsh Hamid

Plus de Araf Karsh Hamid (15)

Dernier

Dernier (20)

Agile, User Stories, Domain Driven Design

Notes de l'éditeur