$30 off During Our Annual Pro Sale. View Details »

Agile, User Stories, Domain Driven Design

Agile, User Stories, Domain Driven Design

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

Araf Karsh Hamid

June 01, 2022
Tweet

More Decks by Araf Karsh Hamid

Other Decks in Technology

Transcript

  1. @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

    View Slide

  2. @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

    View Slide

  3. @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

    View Slide

  4. @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.

    View Slide

  5. @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

    View Slide

  6. @arafkarsh arafkarsh
    Three Mindsets of Product Development
    6
    Design
    Thinking Lean Agile
    Explore the
    Problem
    Build the
    right things
    Build the
    things right
    0

    View Slide

  7. @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)

    View Slide

  8. @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

    View Slide

  9. @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

    View Slide

  10. @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

    View Slide

  11. @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.

    View Slide

  12. @arafkarsh arafkarsh
    Design
    Thinking
    12
    Empathize
    Define
    Ideate
    Prototype
    Test
    Ideate
    Build
    Product
    Measure
    Data
    Learn
    Lean
    Startup
    Design Thinking / Lean Startup

    View Slide

  13. @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

    View Slide

  14. @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

    View Slide

  15. @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

    View Slide

  16. @arafkarsh arafkarsh 16

    View Slide

  17. @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

    View Slide

  18. @arafkarsh arafkarsh
    CAPABILITY CENTRIC DESIGN
    • Business Functions
    • Business process
    • Team structure
    18
    1

    View Slide

  19. @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

    View Slide

  20. @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

    View Slide

  21. @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

    View Slide

  22. @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

    View Slide

  23. @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

    View Slide

  24. @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

    View Slide

  25. @arafkarsh arafkarsh
    User Stories
    • User Stories
    • Behavior Driven Design
    • Writing Good Stories
    • Estimate and Planning
    • Case Study
    25
    Theme / Initiatives Epic User Story Sprint

    View Slide

  26. @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

    View Slide

  27. @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.

    View Slide

  28. @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.

    View Slide

  29. @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.

    View Slide

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

    View Slide

  31. @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.

    View Slide

  32. @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

    View Slide

  33. @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.

    View Slide

  34. @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

    View Slide

  35. @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

    View Slide

  36. @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

    View Slide

  37. @arafkarsh arafkarsh
    User Stories – Case Study
    • Minimum Viable Product
    • Case Study – eCommerce Application – ShopEasy
    • User Journey and Story Map
    37

    View Slide

  38. @arafkarsh arafkarsh
    What exactly
    is a
    Minimum
    Viable
    Product?
    38
    Let us understand this with a case study on eCommerce Shopping Portal.

    View Slide

  39. @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

    View Slide

  40. @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

    View Slide

  41. @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

    View Slide

  42. @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

    View Slide

  43. @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

    View Slide

  44. @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

    View Slide

  45. @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

    View Slide

  46. @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

    View Slide

  47. @arafkarsh arafkarsh
    Shopping Portal – Architects View
    User Journey
    47

    View Slide

  48. @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

    View Slide

  49. @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

    View Slide

  50. @arafkarsh arafkarsh
    Stories – Customer Registration
    User Journey
    50

    View Slide

  51. @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.

    View Slide

  52. @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.

    View Slide

  53. @arafkarsh arafkarsh
    Stories – Shopping : Sprint R1
    User Journey
    53

    View Slide

  54. @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.

    View Slide

  55. @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."

    View Slide

  56. @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."

    View Slide

  57. @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."

    View Slide

  58. @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."

    View Slide

  59. @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.

    View Slide

  60. @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.

    View Slide

  61. @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.

    View Slide

  62. @arafkarsh arafkarsh
    Stories – Shopping : Sprint R2
    User Journey
    62

    View Slide

  63. @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.

    View Slide

  64. @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.

    View Slide

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

    View Slide

  66. @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."

    View Slide

  67. @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.

    View Slide

  68. @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!

    View Slide

  69. @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

    View Slide

  70. @arafkarsh arafkarsh
    Agile
    • Agile Values
    • Scrum
    • Scrum Rules
    • Kanban Boards and cards
    • Kanban vs Scrum
    • Benefits of kanban
    70

    View Slide

  71. @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

    View Slide

  72. @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

    View Slide

  73. @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.

    View Slide

  74. @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

    View Slide

  75. @arafkarsh arafkarsh
    Sprint
    Backlog
    75
    Source: https://www.scrum.org/resources/what-is-scrum

    View Slide

  76. @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

    View Slide

  77. @arafkarsh arafkarsh
    Scrum Values
    77

    View Slide

  78. @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.

    View Slide

  79. @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.

    View Slide

  80. @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

    View Slide

  81. @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.

    View Slide

  82. @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/

    View Slide

  83. @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

    View Slide

  84. @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.

    View Slide

  85. @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/

    View Slide

  86. @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

    View Slide

  87. @arafkarsh arafkarsh
    Agile is
    not
    what
    you do.
    Agility is
    how
    you do
    it.
    87

    View Slide

  88. @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

    View Slide

  89. @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

    View Slide

  90. @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).

    View Slide

  91. @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.

    View Slide

  92. @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.

    View Slide

  93. @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

    View Slide

  94. @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

    View Slide

  95. @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

    View Slide

  96. @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

    View Slide

  97. @arafkarsh arafkarsh
    Domain Driven Design – Tactical Design
    97
    Source: Domain-Driven Design Reference by Eric Evans

    View Slide

  98. @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

    View Slide

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

    View Slide

  100. @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

    View Slide

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

    View Slide

  102. @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/

    View Slide

  103. @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

    View Slide

  104. @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

    View Slide

  105. @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

    View Slide

  106. @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

    View Slide

  107. @arafkarsh arafkarsh
    Domain Driven Design
    • Strategic Design
    • Tactical Design
    o Ubiquitous Language
    o Bounded Context
    o Context Map
    3
    107

    View Slide

  108. @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

    View Slide

  109. @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.

    View Slide

  110. @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?

    View Slide

  111. @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

    View Slide

  112. @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

    View Slide

  113. @arafkarsh arafkarsh
    DDD : Understanding Bounded Context
    Source: Patterns, Principles and Practices of DDD – Page 127 Each of this context will become a Microservice
    113

    View Slide

  114. @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

    View Slide

  115. @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.

    View Slide

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

    View Slide

  117. @arafkarsh arafkarsh
    DDD : Understanding Bounded Context
    Source: Patterns, Principles and Practices of DDD – Page 157
    Microservice is a Bounded Context
    117

    View Slide

  118. @arafkarsh arafkarsh
    Bounded Context &
    Hexagonal Architecture
    • Ports & Adapters – Shopping Portal
    118

    View Slide

  119. @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

    View Slide

  120. @arafkarsh arafkarsh
    Specification Guidelines
    • Approach to understanding
    the Domain
    • Discovering Bounded Context
    120

    View Slide

  121. @arafkarsh arafkarsh
    Problem Space
    121
    Source: Patterns, Principles and Practices of DDD – Page xxxvi

    View Slide

  122. @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

    View Slide

  123. @arafkarsh arafkarsh
    Focus on
    Clean
    Boundaries
    over
    Perfect
    Models
    123
    Source: Patterns, Principles and Practices of DDD – Page 38

    View Slide

  124. @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

    View Slide

  125. @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

    View Slide

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

    View Slide

  127. @arafkarsh arafkarsh
    Solution Space
    127
    Source: Patterns, Principles and Practices of DDD – Page xxxviI

    View Slide

  128. @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.

    View Slide

  129. @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

    View Slide

  130. @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

    View Slide

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

    View Slide

  132. @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

    View Slide

  133. @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

    View Slide

  134. @arafkarsh arafkarsh
    DDD : Context Map
    134
    Source: Domain-Driven Design Reference by Eric Evans
    (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA

    View Slide

  135. @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.

    View Slide

  136. @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.

    View Slide

  137. @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.

    View Slide

  138. @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

    View Slide

  139. @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

    View Slide

  140. @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

    View Slide

  141. @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

    View Slide

  142. @arafkarsh arafkarsh
    Domain Driven Design
    142
    Source: Domain-Driven Design Reference by Eric Evans

    View Slide

  143. @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

    View Slide

  144. @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

    View Slide

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

    View Slide

  146. @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

    View Slide

  147. @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

    View Slide

  148. @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

    View Slide

  149. @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

    View Slide

  150. @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

    View Slide

  151. @arafkarsh arafkarsh
    Communication Synchronous – RPC
    151
    Source: Patterns, Principles and Practices of DDD – Page 212

    View Slide

  152. @arafkarsh arafkarsh
    Communication Async – Event Based
    152
    Source: Patterns, Principles and Practices of DDD – Page 217

    View Slide

  153. @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

    View Slide

  154. @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

    View Slide

  155. @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

    View Slide

  156. @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

    View Slide

  157. @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

    View Slide

  158. @arafkarsh arafkarsh
    Other subsystem
    Anti-corruption layer 365
    Domain
    Driven
    Design
    Your subsystem
    Anti Corruption Layer – ACL
    158

    View Slide

  159. @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.

    View Slide

  160. @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)

    View Slide

  161. @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

    View Slide

  162. @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

    View Slide

  163. @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

    View Slide

  164. @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

    View Slide

  165. @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

    View Slide

  166. @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

    View Slide

  167. @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)

    View Slide

  168. @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

    View Slide

  169. @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

    View Slide

  170. @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

    View Slide

  171. @arafkarsh arafkarsh
    RESTful APIs
    • Standards
    • Api versioning standards
    171
    4

    View Slide

  172. @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

    View Slide

  173. @arafkarsh arafkarsh
    RESTful Guidelines – Query Examples
    173
    Search All
    Products
    Search Products By
    Catalogue ID
    Search Products By
    Catalogue ID & Product ID

    View Slide

  174. @arafkarsh arafkarsh
    RESTful Guidelines – Query Examples
    174
    Two different
    implementation
    of same query

    View Slide

  175. @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

    View Slide

  176. @arafkarsh arafkarsh
    Open API 3.0
    176

    View Slide

  177. @arafkarsh arafkarsh
    Open API 3.0 - POM
    177
    Import Statements in your SpringBoot App

    View Slide

  178. @arafkarsh arafkarsh
    Open API 3.0
    Setup in
    Spring Boot
    App
    178

    View Slide

  179. @arafkarsh arafkarsh
    Open API 3.0
    Setup in
    Spring Boot
    App
    179

    View Slide

  180. @arafkarsh arafkarsh
    Open API 3.0
    Setup in
    Spring Boot
    App
    180

    View Slide

  181. @arafkarsh arafkarsh
    Open API 3.0
    Documentation
    Example
    GET /
    181

    View Slide

  182. @arafkarsh arafkarsh
    Open API 3.0
    Documentation
    Example
    POST /
    182

    View Slide

  183. @arafkarsh arafkarsh
    Open API 3.0
    Documentation
    Example
    PUT /
    183

    View Slide

  184. @arafkarsh arafkarsh
    Open API 3.0
    Documentation
    Example
    DELETE /
    184

    View Slide

  185. @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

    View Slide

  186. @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.

    View Slide

  187. @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

    View Slide

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

    View Slide

  189. @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

    View Slide

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

    View Slide

  191. @arafkarsh arafkarsh 191
    http://www.slideshare.net/arafkarsh

    View Slide

  192. @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

    View Slide

  193. @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

    View Slide

  194. @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

    View Slide

  195. @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

    View Slide

  196. @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.

    View Slide

  197. @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

    View Slide

  198. @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

    View Slide

  199. @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

    View Slide

  200. @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?

    View Slide

  201. @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

    View Slide

  202. @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

    View Slide

  203. @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

    View Slide

  204. @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

    View Slide

  205. @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

    View Slide

  206. @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

    View Slide

  207. @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

    View Slide