Agile, User Stories, Domain Driven Design

@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination
of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 1 Design Thinking / Lean Startup Capability Centric Design Agile (Scrum/Kanban) / Epics / User Stories Architecture Styles & Patterns Domain Driven Design API’s In-Depth / RESTful Open API 3.0 / Swagger Microservice Architecture Series Part 1 of 15 To Build Cloud Native Apps Composable Enterprise Architecture

@arafkarsh arafkarsh 2 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb Cloud-Native Architecture

@arafkarsh arafkarsh 3 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb

@arafkarsh arafkarsh 4 Slides are color coded based on the
topic colors. Design Thinking / Lean / Agile Capability Centric Design User Stories 1 Architecture Styles and Patterns 2 Domain Driven Design 3 RESTful & Open API 3.0 Guidelines 4

@arafkarsh arafkarsh Developer Journey 5 Agile Scrum (4-6 Weeks) 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 Requirement Specs Microservices Domain Driven Design Event Sourcing and CQRS Scrum / Kanban (1-5 Days) Mandatory Infrastructure Design Patterns CI DevOps Event Streaming / Replicated Logs SQL NoSQL CD Container Orchestrator Service Mesh Themes, Epics, Stories, Acceptance Criteria

@arafkarsh arafkarsh 6 100s Microservices 1,000s Releases / Day 10,000s
Virtual Machines 100K+ User actions / Second 81 M Customers Globally 1 B Time series Metrics 10 B Hours of video streaming every quarter Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM 10s OPs Engineers 0 NOC 0 Data Centers So what do NetFlix think about DevOps? No DevOps Don’t do lot of Process / Procedures Freedom for Developers & be Accountable Trust people you Hire No Controls / Silos / Walls / Fences Ownership – You Build it, You Run it.

@arafkarsh arafkarsh 7 50M Paid Subscribers 100M Active Users 60
Countries Cross Functional Team Full, End to End ownership of features Autonomous 1000+ Microservices Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf 1000+ Tech Employees 120+ Teams

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

@arafkarsh arafkarsh Product Mindset 9 Identify the Problem Define the
Value Validate the Outcome Discovery is the new knowing Until proven by market response, outcomes are merely conjectures. The worth of a product is determined by the amount a customer is willing to spend on it. Source: https://www.clearlyagile.com/agile-blog/3-steps-to-grow-our-product-mindset Examples 1. Google Gmail (Search, UI, Storage) 2. Apple iPod ($0.99 Song, UI, Storage)

@arafkarsh arafkarsh Discovery Vs. Delivery 10 Increasing level of Evidence
of Value Increasing level of Effort Developing a product without finding evidence of its value is a waste of time and resources. Observe & Interact Protypes Explainer Videos Landing Pages Concierge MVP Wizard of OZ MVP Beta Release Product Launch Design Thinking Lean Agile Explore the Problem Build the right things Build the things right If You are NOT doing these Then this is waste Single Customer Example Amazon had Human Book Reviewers before they automated it Example Dropbox: Customer interests went up from 5K to 70K

@arafkarsh arafkarsh Design Thinking 11 Empathize 1 Define 2 Ideate
3 Prototype 4 • Who the user is (User Profile / Persona)? • What their needs are? What do they do? Test 5 Is a Philosophy and a set of tools to solve the problem Creatively. Human Centered Design Don’t worry about Technology • From Step 1: Observations, Discoveries, Challenges >> Insights • Defines the Problem • Ideas, Solutions • Potential Matches • Select and Turn the Ideas into • Testable Prototypes • Test with Real users • Gather the Feedback, Observations, New Insights

@arafkarsh arafkarsh Design Thinking Business Thinking Design Thinking Market Analysis
What might be Definitive Iterative Focus Groups Observation Spreadsheets Stories / Scenarios Individual Responsibility Collaboration Permanent Jobs Temporary Projects 12 Tom Klinkowstein – Professor of Design & New Media, New York

@arafkarsh arafkarsh 13 Lean Startup Build Measure Learn Design Thinking
1 Feedback Loop 2 Experiment Observe Don’t Ask 1 2 3 • Movie Streaming (NetFlix), Music Streaming (Spotify), • Drive In Takeaways (McDonalds), Build your furniture (IKEA) 3 Minimum Viable Product (MVP) Eric Ries Video MVP Concierge MVP Wizard of OZ • DropBox Video Demo • Steve Jobs Next OS • Single Customer • Adapt the features to other customers later • Amazon had Human Book Reviewers before they automated it.

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

@arafkarsh arafkarsh Agile Manifesto (Values) 15 INDIVIDUALS AND INTERACTIONS OVER
PROCESSESS AND TOOLS WORKING SOFTWARE COMPREHENSIVE DOCUMENTATION OVER CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION RESPONDING TO CHANGE OVER FOLLOWING A PLAN Source: Agile Manifesto - https://www.scrumalliance.org/resources/agile-manifesto

@arafkarsh arafkarsh Three Mindsets of Product Development 16 Design Thinking
Lean Agile Source: Jonny Schneider, Thought Works Explore the Problem Build the right things Build the things right Hypothesis Validation New Business Requirements Product Evolutions Agile MVP

@arafkarsh arafkarsh 3 Mindset of Product Development 17 Increasing level
of Evidence of Value Increasing level of Effort Developing a product without finding evidence of its value is a waste of time and resources. Observe & Interact Protypes Explainer Videos Landing Pages Concierge MVP Wizard of OZ MVP Beta Release Product Launch Design Thinking Lean Agile Explore the Problem Build the right things Build the things right If You are NOT doing these Then this is waste Single Customer Example Amazon had Human Book Reviewers before they automated it Example Dropbox: Customer interests went up from 5K to 70K The Problem The Solution

@arafkarsh arafkarsh 18

@arafkarsh arafkarsh Design Thinking / Lean / Agile 19 Principles
Foundation 1 Customer Value / Business Value User Centered Approach 2 Work in Short Cycles Evidence based Decision Making 3 Hold Regular Retrospectives Improve the Product 4 Go and See Amplify Good Patterns 5 Test High Risk Hypothesis Focus on High value 6 Do Less More often Understand the Pain points 7 Work as a Balanced Team Small Team works one thing at a time 8 Radical Transparency Transparency through Rituals 9 Incentives Ship software to Deliver Customer Value 10 Learning a 1st Class Citizen of backlog Continuous Learning Source: Jeff Gothelf : Lean vs Agile vs Design Thinking : https://www.youtube.com/watch?v=_4VPfmtwRac Integrate the Principles Not Process

@arafkarsh arafkarsh 1 Capability Centric Design o From Object Modeling
to Process Modeling o Business Solution and Business Process & Data Flow Diagrams o Compare Activity Oriented to Outcome Oriented o Core Principles of Capability Centric Design 20

@arafkarsh arafkarsh From Object Modeling to Process Modeling 21 Developers
with Strong Object Modelling will experience a big Mind Shift to transition to Process based modelling with Events. The Key is: 1. App User’s Journey 2. Business Process 3. Ubiquitous Language – DDD 4. Capability Centric Design 5. Outcome Oriented The Best tool to define your process and its tasks. How do you define your End User’s Journey & Business Process? • Think It • Build It • Run IT

@arafkarsh arafkarsh Business Solution & Process / Capability 22 ❑
Business Solution focuses on the entire Journey of the User, which can run across multiple Microservices. ❑ Business Solution comprises a set of Business Processes / Capability. ❑ A specific Microservice functionality will be focused on a Business Process / Capability. ❑ Business Processes can be divided further into Business Functions

@arafkarsh arafkarsh Levels of Data Flow Diagram 23 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 / Capability Business Function

@arafkarsh arafkarsh System Context Diagram / Data Flow Diagram –
L0 24 • System Context Diagram or Level 0. • An abstraction view • Shows the system as a single process with its relationship to external entities. • It represents the entire system as a single bubble with input and output data indicated by incoming/outgoing arrows.

@arafkarsh arafkarsh Business Solution & Business Process / Capabilities 25
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 Payment Registration Doctors Diagnosis Pharmacy Ward Patient Microservices Business Solution: Patient Hospital Experience Core Domain Sub Domain Sub Domain Sub Domain Sub Domain Generic Domain Sub Domain

@arafkarsh arafkarsh Business Solution & Business Process / Capabilities 26
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 Core Domain Sub Domain Sub Domain Generic Domain Core Domain Sub Domain Generic Domain Order Management Production Scheduling Inventory Management Procurement Management Quality Control Warehouse Management Shipping & Logistics Customer Service Generic Domain Business Solution: Manufacturing – Order Processing Experience

@arafkarsh arafkarsh From Project Based Activity Oriented To Product Based
Outcome Oriented Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html 27 Traditional corporate IT organizations operate in an activity-oriented manner where they fund projects with set time-spans. Organizations that are outcome-oriented align better with business outcomes, but project-based funding undermines long- term effectiveness. Basing funding on products centered around long-term business capabilities creates stable teams that are aligned with business needs. Outcome-oriented thinking compels business capability centered organizations to consider more than just delivering the scope, which is where we want to be. Project based Product based Activity Oriented Outcome Oriented Business Capability Centric

@arafkarsh arafkarsh Business Capability Centric Design 28 Business Centric Development
• Focus on Business Capabilities • Entire team is aligned towards Business Capability. • From Specs to Operations – The team handles the entire spectrum of Software development. • Every vertical will have its own Code Pipeline, Build Pipeline Front-End-Team Back-End-Team Database-Team In a typical Monolithic way, the team is divided based on technology/skill set rather than business functions, leading to bottlenecks and a lack of understanding of the Business Domain. QA Team QA = Quality Assurance PO = Product Owner Vertically sliced Product Team Front-End Back-End Database Business Capability 1 QA PO Ops Front-End Back-End Database Business Capability 2 QA PO Ops Front-End Back-End Database Business Capability - n QA PO Ops

@arafkarsh arafkarsh Core Principles of CCD 29 o Business-Outcome Orientation:
Capabilities align directly to strategic objectives and outcomes, not just operational tasks. o Stable but Evolving Building Blocks: Capabilities are relatively stable over time (e.g., "customer relationship management") even as processes, tools, or structures change around them. o Cross-Functional Integration: CCD encourages breaking down silos, since most capabilities require collaboration across different domains (business, technology, data, operations). o Technology as an Enabler, Not the Starting Point: Systems and platforms are designed to support capabilities, rather than adopting technology first and then finding where to apply it. o Prioritization via Value and Maturity: Capabilities are assessed for current maturity, business criticality, and potential value to guide investment decisions. o Reusable Patterns of Design: By focusing on capabilities, organizations create modular, reusable designs that can be adapted across products, services, or market units.

@arafkarsh arafkarsh Key elements of CCD 30 1. Capability map
(levels 1-3). A visual, hierarchical map of what the enterprise does. Use it to find overlaps, gaps, and priority areas. 2. Value streams capabilities. Link capabilities to the value streams (end-to-end flows that produce outcomes). This shows where a capability contributes to customer value and where to invest. 3. Capability fitness (maturity/health). Assess each capability’s people, process, tech, data, controls, SLOs, and cost. Target weak but critical capabilities for uplift. 4. Capability applications/services mapping. Trace which apps, APIs, and data products implement each capability. This reveals duplication and coupling and guides modernization.

@arafkarsh arafkarsh Key elements of CCD 31 5. Bounded contexts
(DDD). For each important capability, define a bounded context—a coherent language, model, and data boundary. Keep models clean; integrate contexts via explicit contracts/events. 6. Policies & SLOs by capability. Own security controls, compliance requirements, performance SLOs, and cost guardrails per capability (e.g., “KYC must meet X regulation; Onboarding SLO p99 < 800 ms”). 7. Roadmaps & funding via capability-based planning. Plan initiatives as capability uplifts (build, fix, retire). This keeps strategy and spend tied to outcomes rather than projects.

@arafkarsh arafkarsh Key Elements – Expected Outcomes 32 # Artifact
Purpose “Done right” signals 1 Capability Map (L1– L3) Common language for what we do Stable for years; used in portfolio reviews and team design. 2 Value-Stream Capability Matrix Shows where value is created Clear hotspots for investment; fewer hand-offs. 3 Capability Health Scores Prioritize uplift Evidence-based maturity + SLO/Cost/Risk metrics. 4 Capability Services/APIs Map Reduce duplication/coupling One team clearly owns each capability API surface. 5 Bounded Contexts Protect domain models Ubiquitous language per context; explicit contracts/events.

@arafkarsh arafkarsh Summary CCD – Introduction 33 o Organize around
business capabilities—the stable what we do, not the volatile how we do it—to anchor strategy, architecture, and teams. o Create a Capability Map (L1–L3) and link it to value streams/KPIs to expose overlaps, gaps, and high-leverage investment areas. o For each priority capability, define a DDD bounded context with a clear domain language, explicit contracts (APIs/events), and a map of apps/services/data that implement it. o Assign single ownership: one stream-aligned team per capability, supported by platform, enabling, and complicated-subsystem teams to manage cognitive load and speed flow. o Treat policies as part of the contract: SLOs, security/compliance controls, data ownership/versioning, and cost guardrails are owned per capability. o Plan and fund as capability uplifts (build, fix, retire) and track capability fitness (maturity, SLO attainment, unit cost, risk) rather than feature/output counts. o Avoid traps: mirroring org charts, fuzzy boundaries, shared databases across capabilities, and project slices that cut across many capabilities; prefer events + versioned APIs for integration.

@arafkarsh arafkarsh Capability Centric Design - Implementation o How to
implement CCD o Building a Team for CCD o Team Structure & Operating Model o Case Study o Pitfall to Dodge 34

@arafkarsh arafkarsh How to Implement CCD 35 1. Discover &
map. Start with an L1 capability map from strategy docs and customer journeys; decompose top priorities to L2/L3. 2. Connect to value. Attach capabilities to value streams and KPIs. Mark “critical, weak, high-risk” hotspots for uplift. 3. Carve boundaries. For each high-value capability, define its bounded context, core entities, events, and external contracts (APIs/queues). 4. Assign ownership. One team owns one capability API/data product. Avoid shared ownership of core paths. 5. Set SLOs & policies. Security, compliance, and performance SLOs become part of the capability contract. 6. Plan by capability. Create a capability-uplift roadmap (foundational enablers, target state, dependencies), not a feature list.

@arafkarsh arafkarsh Building a Team for CCD 36 CCD pairs
beautifully with Team Topologies. Use these four team types to match capability boundaries and flow of change: o Stream-aligned teams own a capability end-to-end (“you build it, you run it”). o Platform teams offer reusable infrastructure and internal products that accelerate stream teams. o Enabling teams coach on gaps (e.g., data, SRE, security). o Complicated-subsystem teams take on gnarly internals to reduce cognitive load for everyone else.

@arafkarsh arafkarsh Team Structure 37 Typical stream-aligned (capability) team makeup
o Product Manager/Owner (value & roadmap tied to capability KPIs) o Lead/Staff Engineer (tech strategy & contracts) o Backend/API & Frontend engineers (if capability is user-facing) o Data engineer/analyst (events, data product, quality) o SRE/Platform liaison (SLOs, reliability, cost) o Security/Compliance liaison (policy as code, audits)

@arafkarsh arafkarsh Engineering Pod (Team) Size 38 5 Manager Architect
Sr. Engineer Engineers 7 Manager Architect Sr. Engineer Engineers Engineering Pods are created based on Various Team Size Configurations As per Business Capability Requirement • 5 Members • 7 Members • 9 Members

@arafkarsh arafkarsh Roles & Responsibilities 39 Category Role Type Responsibilities
1 Customer Product Owner External • Complete Product Vision • Specifications 2 Engineering Pod Cloud Manager / Analyst Internal • Analyst & Specifications (User Stories, Acceptance Criteria) • Feature Management in Production & Focused on Outcome • Scrum Master & Team Management 3 Engineering Pod Cloud Architect Internal • Technology Stack, Mentor / Guiding Team on Technology • Data Models and Interface Definitions (Hexagonal Architecture) • Research & Coding (Feature and Infra Code) 4 Engineering Pod Cloud Sr. Engineer Internal • Mentor / Guiding Team on Technology • All the Responsibilities of Cloud Engineer also 5 Engineering Pod Cloud Engineer / SRE Internal • Feature Coding (Open API Specs) • Feature Test Cases (Unit, Component, Contract, Integration) • Infra Coding (Infra, Security, Network) • Build Pipeline Automation 6 Engineering Pod Cloud Network / Security Lead External • Define Network Policies • Define Security Policies • Review Infra Code for Network & Security Policies 7 Engineering Pod Cloud User Experience Lead External • Usability Guidelines • Data Flow Guidelines

@arafkarsh arafkarsh Operating Model 40 o One team one capability
(or tightly related sub- capabilities). o Team has clear inbound/outbound contracts: APIs, events, SLAs, and change policies. o Cross-capability dependencies handled with published events and versioned APIs; never hidden DB joins. o Funding and goals measured as capability fitness improvements (SLOs, cycle time, risk posture, unit cost).

@arafkarsh arafkarsh RACI Sketch 41 o Responsible: Stream-aligned team o
Accountable: Capability Product Owner o Consulted: Platform, Security, Data Governance, Risk/Compliance o Informed: Adjacent capability owners, Portfolio/PMO

@arafkarsh arafkarsh Case Study: Payment Settlement 42 o Bounded context:
Payment (Authorize, Capture, Refund, Reconcile) with events like PaymentAuthorized, PaymentCaptured, RefundIssued. o Contracts: REST/GraphQL for sync ops; Kafka topics payments.events.* for async. o SLOs: p99 ≤ 300 ms for authorization; availability ≥ 99.95%; ledger integrity guarantees. o Team: Stream-aligned “Payments” squad; Platform provides secrets, observability, PCI tooling; Enabling team helps with risk modeling. o Roadmap: “Improve authorization success rate by 1.5%” and “Cut reconciliation time by 80%”—both are capability outcomes, not features.

@arafkarsh arafkarsh Pitfalls to Dodge 43 o Treating “capability” as
a synonym for department— breaks when org charts shift. o Mapping processes before capabilities—start with what, then how. o Owning the same entity in multiple capabilities—use clear bounded contexts and contracts. o Project funding that slices across many capabilities— return to capability-based planning and invest where outcomes live.

@arafkarsh arafkarsh Playbook to run with your teams. 44 1.
Draft the L1-L3 capability map and validate with business leads. 2. Link to value streams and KPIs; score capability health. 3. Draw bounded contexts and contracts for top capabilities. 4. Stand up stream-aligned teams per capability; support with platform/enabling teams. 5. Fund and roadmap by capability uplift, measure via SLOs/fitness KPIs.

@arafkarsh arafkarsh Summary: CCD – Implementation 45 o Implement: Draft
an L1–L3 capability map and link it to value streams/KPIs to surface overlaps, gaps, and hotspots to fix first. o Design: For priority capabilities, carve DDD bounded contexts with clear domain language and explicit contracts (APIs/events); map apps/services/data ownership to each. o Govern: Make SLOs, security/compliance controls, and cost guardrails part of each capability’s contract; plan & fund via capability-uplift roadmaps tied to measurable outcomes. o Team structure: Stand up one stream-aligned team per capability, supported by platform, enabling, and complicated-subsystem teams; staff with PO/PM, lead engineer, FE/BE, data, and SRE/security liaisons. o Operating model: Enforce single ownership and inbound/outbound contracts; handle dependencies via events + versioned APIs (never shared DB joins); measure capability fitness (SLO attainment, cycle time, risk, unit cost). o RACI sketch: Responsible: stream-aligned team; Accountable: capability Product Owner; Consulted: platform, security, data governance, risk/compliance; Informed: adjacent capability owners and portfolio/PMO. o Pitfalls to dodge: Mirroring org charts, fuzzy boundaries, shared databases, process-before-capability mapping, project funding that slices across many capabilities, and tight coupling that bypasses contracts.

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

@arafkarsh arafkarsh User Story 47 Role-Feature-Reason Matrix Story Card These
three elements (WHO, WHAT, WHY) are the building blocks of User stories. Element Example Role WHO: As an e-Commerce Retailer Feature WHAT: I want to know who my Gold Customers are Reason WHY: So that I sell more Element Definition WHO: Establishes the user or users or another service. WHAT: Describes the Activity – Key Axis of the Story. What the user does in the story. WHY: This describes the purpose of the story. Source: User Story A Pragmatic View, Page 9. Published 0ct 19, 2019 User stories are NOT 1. IEEE 830 Software Specs 2. Use Cases Use Cases are a combination of User Story and Acceptance Criteria 3. Scenarios

@arafkarsh arafkarsh Acceptance Criteria / Behavior Driven Development 48 Source:
https://dannorth.net/introducing-bdd/ Given Customer John Doe exists When he buys products ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Acceptance Criteria The definition of Done – As per Scrum These three elements (GIVEN WHEN THEN) are the building blocks of Acceptance Criteria. Typical SDLC Life Cycle Analyst Specifies the Use Case Developer The developer builds software based on Specific Usage scenarios with respect to the Use Case. Tester Tester builds test cases based on Use Case Scenarios and finds issues. The Gaps identified in this process are filled up by linking the User Stories with Acceptance Criteria.

@arafkarsh arafkarsh INVEST in Good Stories 49 Source: INVEST in
Good Stories, and SMART Tasks https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ Term Description I Independent No overlapping but independent Stories. 3 Forms of Dependencies 1. Overlap 2. Order 3. Containment. N Negotiable A good story is not an explicit contract for features. A good story captures the essence and not the details. Over a period, a Story may attract special notes, test ideas and others. However, this is not required to prioritize and schedule the story. V Valuable Story must be valuable to the customer. E.g., (IRACIS) Increase Revenue, Avoid Cost, Improve Service. E Estimable An estimate (not necessarily precise) but to focus on priority and implementation. You can use Function Points, COCOMO etc. S Small Any story that goes beyond few weeks is big and may be ambiguous. It’s important to keep the Story small. T Testable A good story is testable. Testable story clearly establishes the spec from Customer perspective.

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

@arafkarsh arafkarsh User Stories – Small Stories 51 • User
Story should take a maximum of 3-5 person days to complete the story. (From Analysis + Design + Deploy + Test + Fix + Re-Deploy) • User Stories can be smaller from a few hours to 1-2 Person days. • Each story can have 3-7 Acceptance criteria. • Sprint backlog will be having 6-10 stories. • If a story survives more than 1 sprint, then the story needs to break down into smaller stories. Source: User Story A Pragmatic View, Page 78-80. Published 0ct 19, 2019

@arafkarsh arafkarsh Features of BDD 52 • Focus on Behavior
of the System rather than tests. • Collaboration between Business Stake holders, Analysts, Developers, QA. • Ubiquitous Language • Driven By Business Value • Extends Test Driven Development Source: https://cucumber.io/ Cucumber merges specification and test documentation into one cohesive whole.

@arafkarsh arafkarsh User Story / Behavior Driven Development 53 Source:
https://dannorth.net/introducing-bdd/ As an an e-Commerce Retailer I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys products ABC for $1000 USD Then He becomes a Gold Customer Role-Feature-Reason Matrix As a Customer I want to withdraw Cash from ATM So that I don’t have to wait in line at the bank Given The account is in Credit AND the Card is Valid AND the dispenser contains Cash Role-Feature-Reason Matrix When The Customer requests Cash Then Ensure that the Account is debited AND Ensure cash is dispensed AND ensure that Card is returned. BDD Construct Acceptance Criteria BDD Construct Acceptance Criteria User Story – 1 User Story – 2

@arafkarsh arafkarsh Estimate – Story Points / Velocity 54 Story
Point – An Ideal day’s work (8 Hour). Means – no meetings, no emails, no phone calls etc. 1. Clarifying with Customer 2. Time to Develop 3. Write Test Cases 4. Testing 5. Deploy 6. Verify The key over here is Reasonable rather than being Precise. Source: User Stories Applied by Mike Cohn Velocity Velocity is the number of story points the team completes in an iteration.

@arafkarsh arafkarsh Planning – MoSCoW Rules 55 Code Priority Description
Mo Must Have These features are fundamental to the Application S Should Have These are important however; work arounds are available. Co Could Have Can be left out if the developer runs out of time. W Won’t Have Feature can be planned in a future release. Release Plans • All the story points prioritized as per the customer • Story Points are mapped to a set of iterations. • Estimated Velocity for each Iteration • For Ex. If there are 200 Story Points • 20 Story Points are allocated at each Iteration • Then 10 iteration is required

@arafkarsh arafkarsh Story Anti-Patterns 56 Anti Pattern Details 1 Too
Small Story 1. Export Report in Excel Format Story 2. Export Report in PDF Format. These can be combined to a Single story. 2 Interdependent Stories This can cause planning issue. Remove the dependency or combine into a Single Story. 3 Gold Plating Addition of un-necessary features by the developers. 4 Too Many Details Too much time is spent in gathering details. 5 Early UI Definition Including UI details too soon 6 Look Ahead Upfront Large Requirements gathering. 7 Splitting Too many stories 1. The Story is too large to fit into the iteration 2. Story contains High Priority and Low Priority items. 8 Unable to Prioritize Prioritization will be difficult if the business value can’t be determined Source: User Stories Applied by Mike Cohn. Page 191

@arafkarsh arafkarsh Why User Stories • User stories emphasize verbal
communication. • User stories are comprehensible by everyone. • User stories are the right size for planning. • User stories work for iterative development. • User stories encourage deferring detail. • User stories support opportunistic design. • User stories encourage participatory design. • User stories build up tacit knowledge. 57 Source: User Stories Applied by Mike Cohn. Page 178

@arafkarsh arafkarsh User Stories – Case Study • Non-Functional Requirements
• Minimum Viable Product • Case Study – eCommerce Application – ShopEasy • User Journey and Story Map 58

@arafkarsh arafkarsh Non-Functional Requirements 59 Disaster Recovery Business Continuity Security
& Compliances Application Performance Load & Scalability High Availability 1 2 3 4 5 6

@arafkarsh arafkarsh Non-Functional Requirements 60 As a system administrator, I
want the system to automatically switch to a backup data centre in the event of a failure, So that services are restored quickly and data loss is minimised. Role-Feature-Reason Matrix User Story - 1: Disaster Recovery BDD Acceptance Criteria – 1: Failure Given a major data centre failure When the system detects the failure Then it must automatically failover to a secondary data centre with minimal service disruption. BDD Acceptance Criteria – 2 : RPO / RTO Given the system has failed over to a secondary data centre, When recovery processes are initiated, Then The Recovery Point Objective (RPO) must not exceed 5 minutes AND the Recovery Time Objective (RTO) must not exceed 30 minutes. BDD Acceptance Criteria – 3 : Data Loss Given a data recovery process, When data is restored, Then data loss must not exceed the last 5 minutes of data prior to the disruption.

@arafkarsh arafkarsh Non-Functional Requirements 61 As a business manager, I
want the system to maintain operational capability during component failures, So that business processes can continue without interruption. Role-Feature-Reason Matrix User Story - 2: Business Continuity BDD Acceptance Criteria – 1: Failure Given a failure in one of the main operational components, When the failure occurs, Then the system must continue operations using redundant components without manual intervention. BDD Acceptance Criteria – 2 : Data Given the system is operating under failure conditions, When data is being processed, Then it should synchronize in real-time with backup components to maintain data integrity.

@arafkarsh arafkarsh Non-Functional Requirements 62 As a As a security
officer, I want the system to adhere to data encryption standards and enforce strict access controls, So that the system remains compliant with GDPR and other privacy laws. Role-Feature-Reason Matrix User Story - 3: Security & Compliance BDD Acceptance Criteria – 1: Data Given data storage and transfer processes, When data is handled by the system, Then all personal data must be encrypted both at rest and in transit using industry-standard methods. BDD Acceptance Criteria – 2 : Authorization / Log Given any access request to sensitive data, When the request is processed, Then the system must enforce role-based access controls AND log the activity in the audit trail.

@arafkarsh arafkarsh Non-Functional Requirements 63 As a customer support manager,
I want the system to achieve 99.99% uptime, So that customers can reliably access our services at any time. Role-Feature-Reason Matrix User Story - 4: High Availability BDD Acceptance Criteria – 1 : Failure Given an instance of server failure, When the failure is detected, Then the system must automatically reroute traffic to active instances without user impact. BDD Acceptance Criteria – 2 : Upgrades Given maintenance or update procedures, When these procedures are executed, Then they must not affect the availability of the system.

@arafkarsh arafkarsh Non-Functional Requirements 64 As a product owner, I
want the system to handle up to 1 million concurrent users efficiently, So that the performance remains stable as the user base grows. Role-Feature-Reason Matrix User Story - 5: Load & Scalability BDD Acceptance Criteria – 1 : Load Given an increase in user load to the system, When the number of active users approaches 1 million, Then the system must automatically scale resources to maintain performance. BDD Acceptance Criteria – 2 : Scalability Given a quarterly scalability test, When the test is conducted, Then the system must demonstrate its ability to maintain response times under high load conditions.

@arafkarsh arafkarsh Non-Functional Requirements 65 As a user, I want
the application to load quickly and respond rapidly to my inputs, So that my experience is efficient and free from frustrating delays. Role-Feature-Reason Matrix User Story - 6: App Performance BDD Acceptance Criteria – 1 : Performance Given any user action that requires a page load, When the page is accessed, Then it must load within 3 seconds for 90% of attempts under typical load conditions. BDD Acceptance Criteria – 2 : Performance Tx Given any transaction is initiated by the user, When the transaction is processed, Then it must be completed within 2 seconds for 95% of transactions.

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

@arafkarsh arafkarsh Example 1: eCommerce / Checkout Experience 67 Theme
/ Initiative Epic User Story Sprint ShopEasy / Checkout Experience 1. Simplify Checkout process 2. Multiple Payment options 3. Order Tracking 4. Inventory Management 5. Notifications 2. Multiple Payments Release 1 1. Debit Card Release 2 1. PayPal Payment 2. UPI Payment Release 3 1. Credit Card 2. Net Banking Stories 1. Credit Cards 2. Debit Cards 3. Net Banking 4. UPI Payment 5. PayPal Payment 6. Cash on Delivery 7. Save Payment info

@arafkarsh arafkarsh Example 2: SCM / Inventory Streamlining 68 Theme
/ Initiative Epic User Story Sprint SCM / Inventory Streamlining 1. Order Management 2. Inventory Management 3. Supplier Management 4. Notifications 2. Inventory Mgmt Release 1 1. Add / Update Products 2. Stock Levels Release 2 1. Stock Thresholds Release 3 1. Inventory Reports 2. Stock Auto Refill 3. Stock Optimizations Stories 1. Add / Update Products 2. Stock Levels 3. Inventory Reports 4. Stock Thresholds 5. Stock Optimizations 6. Stock Auto Refill SCM = Supply Chain Management

@arafkarsh arafkarsh Example 3: Space Shuttle Launch 69 Theme /
Initiative Epic User Story Sprint Shuttle Launch / Pre-Launch Preparation 1. Develop & Test Shuttle Systems 2. Astronaut Training 2. Training Release 1 1. Mission Training Release 2 1. Emergency Training Stories 1. Mission Training 2. Emergency Training Shuttle Launch / Launch Execution 1. Coordinate Launch Logistics 2. Monitor and Control Launch Operations Stories 1. Launch Sequence 2. Comm with Astronauts 2. Monitor & Control Release 1 1. Launch Sequence 2. Comm with Astronauts

@arafkarsh arafkarsh Example 4: Manufacturing & Supply Chain 70 Theme
/ Initiative Epic User Story Sprint Manufacturing / Supply Chain 1. Order 2. Inventory 3. Procurement & Mgmt 4. Production Scheduling 5. Quality Control 6. Warehouse Management 7. Shipping & Logistics 8. Customer Service 4. Production Release 1 1. Prioritize Production orders 2. Optimise Resource Allocation Release 2 1. Reschedule Delayed Jobs 2. Generate Real-Time Production Reports 3. Notify Production Milestones Stories 1. Prioritize Production orders 2. Optimise Resource Allocation 3. Reschedule Delayed Jobs 4. Generate Real-Time Production Reports 5. Notify Production Milestones

@arafkarsh arafkarsh Example 5: Healthcare App 71 Theme / Initiative
Epic User Story Sprint Healthcare / We Care 1. Patient 2. Healthcare Staff 3. Appointments 4. Diagnosis 5. Lab 6. Pharmacy 7. Auth 4. Diagnosis Release 1 1. Pre-Checkup 2. Search Medical History 3. Diagnosis & Prescription Release 2 1. Prescribe for Lab Tests Stories 1. Pre-Checkup 2. Search Medical History 3. Diagnosis & Prescription 4. Prescribe for Lab Tests

@arafkarsh arafkarsh User Journey with Story Map & Release Cycles
72 1. Register 3. Make Appointment 4. Diagnosis and Prescription 6. Get Medicine 5. Lab Tests Health Staff Appointment Pharmacy Lab Diagnosis 2. Search & Select Doctor Patient User Journey Minimum Viable Product Upload Medical Docs Add Doctor / Nurse Cancel Appointment R2 Lab Tests View Medical History Duty Calendar R3 Reschedule Register Search Doctor Available Dates Book Appointment Medical History Check Verify Prescription Pack Medicines R1 Pre-Checkup Diagnosis & Prescription Appointment Upload Results Schedule Duty Time Make Payment Share Medical Docs R4 Appointment Calendar Make Payment View Appointments Email SMS

@arafkarsh arafkarsh Example 6: Digital Banking Platform 73 Theme /
Initiative Epic User Story Sprint Digital Banking / Personal Banking 1. Customer Account Mgmt 2. Transaction Mgmt 3. Fraud Detection 4. Notification / Alerts 5. Account Mgmt 6. Authentication 2. Tx Mgmt Release 1 1. Fund Transfer UPI 2. View Tx Release 2 1. Fund Transfer NEFT 2. Fund Transfer IMPS Release 3 1. Fund Transfer RTGS 2. Download Tx Stories 1. Fund Transfer UPI 2. Fund Transfer NEFT 3. Fund Transfer IMPS 4. Fund Transfer RTGS 5. View Tx 6. Download Tx

@arafkarsh arafkarsh User Journey with Story Map Account Mgmt KYC
Link Aadhaar Link Pan Card Add Receiver List Receiver Deactivate User Banking Experience Create Account Set Notification Fund Transfer Validate Tx Set Alerts Add Receiver User Journey EMail SMS Set Alerts Flag Suspicious Tx Notify Customer Block Tx Customer Mgmt Account Mgmt Tx Mgmt Notification Fraud Detection Alerts View Tx Fund Transfer UPI Download Tx Fund Transfer NEFT Fund Transfer IMPS

@arafkarsh arafkarsh Epic – Customer Account Management 75 As a
customer I want to create an account So that I can deposit money, withdraw, and manage my finances. Role-Feature-Reason Matrix User Story – 1 : Customer Registration BDD Acceptance Criteria – 1: Save User Given The fields First Name, Last Name, DOB Address, Email Address, Phone No. When The user enters values in the fields First Name, Last Name, DOB Address, Email Address, and Phone No. Then If the following fields contain values First Name, Last Name, Address, Email Address, and Phone No. AND Age is greater than 18, then Save the Data. BDD Acceptance Criteria – 2 : Generate Password Given User Info Available When The email address is a valid email id. Then Generate the Password AND Send mail with the user email address as login id and the URL of the portal AND Send the Password to a separate email address. AND Store data on mail status as mail sent or failed. BDD Acceptance Criteria – 3 : Resend Mail Given User Registration mail status is available. When The Mail status is equal to "Failed". Then Send the mail again AND store the attempt number.

@arafkarsh arafkarsh Epic – Receiver Account Management 76 As a
customer I want to add a Receiver Account So that I can do a Fund Transfer to that account Role-Feature-Reason Matrix User Story – 1 : Add Receiver Account BDD Acceptance Criteria – 1: Save Receiver Given The customer provides valid receiver account details – Name, IFSC Code, Bank Account When The user enters values in the fields Name, IFSC Code, Bank Account Then If the following fields contain values Name, IFSC Code, Bank Account, then Save the Data with a flag saying Pending for OTP Verification. BDD Acceptance Criteria – 2 : Send OTP Given Receiver Info Available When Send the OTP in SMS or Email Then Store OTP for verification by the Customer AND store the Expiry time greater than the Current time, BDD Acceptance Criteria – 3 : OTP Verification Given OTP Number by the Customer When OTP is verified with database AND its valid AND not Expired Then Change the Receiver status to Verified AND the max transaction value allowed for 24 hours is Rs. 50,000/-

@arafkarsh arafkarsh Epic – Transaction Management 77 As a customer
I want to Select a Receiver Account So that I can do a Fund Transfer to that account Role-Feature-Reason Matrix User Story – 1 : Fund Transfer BDD Acceptance Criteria – 1: Initiate Fund Transfer Given A customer provides valid receiver details and transfer amount, When they initiate the transfer Then the transaction is processed, AND generates OTP for verification BDD Acceptance Criteria – 2 : Validate Tx Given a transfer amount exceeds the daily limit When the customer initiates the transaction Then The system rejects the transfer with a limit exceeded message. BDD Acceptance Criteria – 3 : OTP Verification Given OTP Number by the Customer When OTP is verified with database AND its valid AND not Expired Then The transaction is processed, and the balances are updated.

@arafkarsh arafkarsh Example 7: eCommerce Portal / Shop Easy 78
Theme / Initiative Epic User Story Sprint eCommerce / Shop Easy 1. Customer Management 2. Search Product 3. Catalogue 4. Shopping Cart 5. Order Processing 6. Payments 2. Search Product Release 1 1. Global Search Release 2 1. Search by Brand 2. Search by Price Range Release 3 1. Search by Model 2. Search by Rating Stories 1. Global Search 2. Search by Brand 3. Search by Price Range 4. Search by Model 5. Search by Rating

@arafkarsh arafkarsh User Journey with Story Map 79 Global Search
Search by Brand Search by Price Search by Model Search by Rating Product Details Image Gallery Product Reviews User Shopping Experience Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Add to Cart Update Qty Delete Item Make Payment Confirm Order Pay Credit Card Pay Debit Card Use PayPal Select Address Registration

@arafkarsh arafkarsh User Journey with Story Map & Release Cycles
80 Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use PayPal R2 Search by Brand Product Reviews Pay Debit Card R3 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Search by Model Search by Rating R4 Minimum Viable Product

@arafkarsh arafkarsh Shopping Portal – Architects View User Journey 81

@arafkarsh arafkarsh 82 Shopping Portal /Web App /Authentication /product /review
API Gateway Nodes Firewall Web App Pod Web App Pod Web App Service N2 N1 Product Pod Product Pod Product Pod Product Service N4 N3 MySQL DB Review Pod Review Pod Review Pod Review Service N4 N3 N1 Users Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP) Mongo DB Mongo DB Auth Pod Auth Pod Auth / Authorize Service N3 N5 MySQL DB Generates Token (JWT) Services will process requests only if the token is valid

@arafkarsh arafkarsh 83 Shopping Portal /Customer /Shopping Cart /Order Load
Balancer API Gateway Nodes Firewall Order Pod Order Pod Order Pod Order Service N4 N3 MySQL DB Users Payment Pod Payment Pod Payment Service N4 N3 Cart Pod Cart Pod Cart Pod Cart Service N1 N2 N2 Redis DB Services will process requests only if the token is valid External Payment Service Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP) Customer Pod Customer Pod Customer Service N1 N2 Redis DB

@arafkarsh arafkarsh Stories – Customer Registration User Journey 84

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

@arafkarsh arafkarsh Epic – Auth 86 As a Consumer I
want to login to eCommerce Portal So that I can buy products Role-Feature-Reason Matrix User Story – 2 : Portal Login BDD Acceptance Criteria – 1 : Authentication Given The user clicks the login page, and the portal goes to the login page with the fields login id and continue button. When The user enters the login id and clicks the continue button, and the page shows the password page. AND the user enters the Password and clicks the sign-in button. Then The system validates the credentials, and IF the credentials are valid, then the user is allowed to do the shopping. Else access denied message is shown. BDD Acceptance Criteria – 2 : Authentication Given The Request is authenticated. When The Input contains the login id and Password. Then The system validates the credentials, and IF the credentials are valid, then the user is allowed to do the shopping. Else access denied message is shown.

@arafkarsh arafkarsh Stories – Shopping : Sprint R1 User Journey
87

@arafkarsh arafkarsh Epic – Search (Product) 88 As a Consumer
I want to search for a product So that I can buy products Role-Feature-Reason Matrix User Story – 1 : Global Search BDD Acceptance Criteria – 1 : Global Search Given The user logged into the portal, and the product search page was available. When The user enters the product name and clicks search Then The system search for the Product, and IF it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, Product Image ELSE returns zero records. BDD Acceptance Criteria – 2 : Global Search Given The Request is authenticated. When Input contains Product Name Then The system search for the Product, and IF it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, Product Image ELSE returns zero records.

@arafkarsh arafkarsh Epic – Product Page 89 As a Consumer
I want to check a Product So that I can buy the Product Role-Feature-Reason Matrix User Story – 1 : Show Product BDD Acceptance Criteria – 1: Show Product Given The user logs into the portal, a Product is searched, and results are available. When The user then clicks a product for product details Then The system will show product details based on the product ID with following details. Product Name, Product Rating, Price, Product Description and Image, and buttons to " Add to Cart" and "Buy Now." IF the Product is not available, then the system will show the error "Selected Product details are not available." BDD Acceptance Criteria – 2: Retrieve Product Given The Request is authenticated When The Input contains Product id Then The system will return the product details based on the product ID with the following details. Product Name, Product Rating, Price, Product Description, and Image IF the Product is not available, then the system will show the error "Selected Product details not available."

@arafkarsh arafkarsh Epic – Shopping Cart 90 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."

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

I want to Delete a Product from the Cart So that I can buy other items in the Cart. Role-Feature-Reason Matrix User Story – 3 : Delete from Cart BDD Acceptance Criteria – 1: Delete From Cart Given The user logs into the portal and clicks the Shopping Cart, and the cart displays all the items. When The user then clicks Delete Button for a Product. Then The system will delete the Item (Product) from the Cart and update the Item counter in the Cart Icon. AND deletes an item from the Cart DB AND if the delete fails, the system shows an Error" Unable to Delete Product from the Cart." BDD Acceptance Criteria – 2: Delete item Given The Request is authenticated. When The Input contains the user login id and Product id. Then The system will delete the Item (Product) from the cart DB AND if the delete fails, the system shows an Error "Unable to Delete Product from the Cart."

@arafkarsh arafkarsh Epic – Customer 93 As a Consumer I
want to Select Shipping Address So that I can ship the items to that Address Role-Feature-Reason Matrix User Story – 3 : Select Address BDD Acceptance Criteria – 1 : Show Address Given The user is on the Shopping Cart Page. When The user Clicks Proceed to Buy Button. Then The System shows the Available Addresses for Shipping. BDD Acceptance Criteria – 2 : Select Address Given The user in the Shopping Cart Page with Available Shipping Address When The user Selects the Address and Clicks Proceed to Buy. Then The System saves the Temp Order details from Items from Shopping and Selected Shipping Address AND these details are valid only for the user session. If the order is not placed, Temp Order items will be put back in Cart DB. BDD Acceptance Criteria – 3 : Save Temp Order Given The Request is authenticated. When The input contains the user login id, items, and shipping address. Then The System saves the Temp Order details from Items from Shopping and Selected Shipping Address AND these details are valid only for the user session. If the order is not placed, Temp Order items will be put back in Cart DB.

@arafkarsh arafkarsh Epic – Order : Credit Card 94 As
a Consumer I want to Process the Order So that I can buy Products Role-Feature-Reason Matrix User Story – 1 : Process Order BDD Acceptance Criteria – 1 : Add Payment Given The user is on the Order Page with Items and selected Shipping Address. When The user Selects the Payment Option As a Credit Card AND Input the Credit Card Details in the following fields Card Name, Card No. Expiry Date (MM/YYYY), CVV Number. Then The System Validates the Credit Card Number and the Expiry Date, Card Name & CVV. These data Must NOT be Null IF Invalid, THEN Systems say invalid Payment details, ELSE Saves the info and proceeds with the payment. BDD Acceptance Criteria – 3 : Save Payment Given The Request is authenticated. When The input contains the user login id, order id, and payment details (card number only last four digits). Then The System Validates the Credit Card Number and the Expiry Date, Card Name & CVV. These data Must NOT be Null IF Invalid, THEN Systems say invalid Payment details, ELSE Saves the following info Card Name, Card Number (only last 4 digits), Expiry Date and proceeds with the payment. BDD Acceptance Criteria – 3 : Payment Gateway Given The Request is authenticated. When The input contains Valid payment details. Then The Request with the valid Payment Details, the System calls the External Payment Service for Payment Processing and Returns the Result to the Calling System.

@arafkarsh arafkarsh Epic – Payment 95 As a Consumer I
want to Make a Payment So that I can buy Products Role-Feature-Reason Matrix User Story – 1 : Make Payment BDD Acceptance Criteria – 1 : Process OTP Given The user Enters the Payment Details and Clicked Proceed to Buy, and the System shows the Payment Service Page. When The user Enters One Time Password (OTP) and clicks Proceed. Then The System Sends the OTP to the External Payment Gateway, and the result is returned to the Caller. BDD Acceptance Criteria – 2 : Order Status Given The Request is authenticated. When The input contains Payment Status. Then IF the Payment is successful, the Order Status is changed to Successful ELSE, the items are returned to the Cart.

@arafkarsh arafkarsh Stories – Shopping : Sprint R2 User Journey
96

@arafkarsh arafkarsh Epic – Auth 97 As a Consumer I
want to Reset the Password So that I can log in to Portal. Role-Feature-Reason Matrix User Story – 3 : Forgot Password BDD Acceptance Criteria – 1 : Forgot Password Given The Request is authenticated. When The Input contains the login id and password. Then The System validates the email address and the security question AND if they are valid, then the system re- generates the password AND Stores the password (Hashed) AND send the new password in an email to the user. AND Stores the status of email delivery. BDD Acceptance Criteria – 2 : Forgot Password Given The login page contains Forgot Password link. When The user clicks Forgot Password link then the page shows Forgot Password Page, AND the user enters their Email Address and clicks the continue button AND then, the page goes to the security page, and the user enters the security question and clicks the reset password button. Then The System validates the email address and the security question AND if they are valid, then the system re- generates the password AND Stores the password (Hashed) AND send the new password in an email to the user. AND Stores the status of email delivery.

@arafkarsh arafkarsh Epic – Search (Product: Price Range) 98 As
a Consumer I want to search for a Product within a price range So that I can buy Products. Role-Feature-Reason Matrix User Story – 2 : Search By Price Range BDD Acceptance Criteria – 1: By Price Range Given The user logged into the Portal, and the product search page was available. When The user enters the Product name AND the Price Range & clicks search. Then The System search for the Product within the Price Range, and if it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, and Product Image. Else returns zero records. BDD Acceptance Criteria – 2: By Price Range Given The Request is authenticated. When The Input contains the Product name AND the Price Range. Then The System search for the Product within the Price Range, and if it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, and Product Image. Else returns zero records.

@arafkarsh arafkarsh Epic – Product Page 99 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."

I want to Update the Quantity of a Product in the Cart So that I can buy the Product. Role-Feature-Reason Matrix User Story – 3 : Update the Cart BDD Acceptance Criteria – 1: Update Quantity Given The user logs into the Portal and clicks the Shopping Cart, and the Cart displays all the items. When The user then inputs the Quantity for a Product. Then The System ensures that the Quantity is greater than ZERO AND the System will update the Quantity in the cart DB. AND if there is an error in updating System will show "Unable to update the Quantity." BDD Acceptance Criteria – 2: Update Quantity Given The Request is authenticated. When The Input contains the user login id, product id, and Quantity. Then The System ensures that the Quantity is greater than ZERO AND the System will update the Quantity in the cart DB. AND if there is an error in updating System will show "Unable to update the Quantity."

@arafkarsh arafkarsh Epic – Order : PayPal 101 As a
Consumer I want to Process the Order So that I can buy Products Role-Feature-Reason Matrix User Story – 1 : Process Order BDD Acceptance Criteria – 1 : Add Payment Given The user is on the Order Cart Page with Items and selected Shipping Address. When The user Selects Payment Option As PayPal AND Input the PayPal Details. Then The System Validates the PayPal Details IF Invalid, Then the System returns "Invalid Payment details." ELSE Saves the info and proceeds with Payment. BDD Acceptance Criteria – 3 : Save Payment Given The Request is authenticated. When The input contains the user login id, order id, and payment details (PayPal Details). Then The System Validates the PayPal Details IF Invalid, Then the System returns "Invalid Payment details." ELSE Saves the info and proceeds with Payment. BDD Acceptance Criteria – 3 : Payment Gateway Given The Request is authenticated. When The input contains Valid payment details. Then The Request with the Valid Payment Details, the System calls the External Payment Service for Payment Processing and Returns the Result to the Calling System.

@arafkarsh arafkarsh 102 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 UPI 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 UPI Kanban Cycle: Each of the Stories can be released without waiting for other stories to be completed resulting in Shorter Releases as all the stories are independent!

@arafkarsh arafkarsh Summary: Business Capability Centric Design 103 1. Business
Solutions o 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 Functions 1 User Stories BDD Story Points MVP – User Journey Business Functions n Business Functions 1 Business Functions n Business Functions 1 Business Functions n Capabilities

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

@arafkarsh arafkarsh Agile Values 105 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 Key in Microservices Architecture

@arafkarsh arafkarsh Scrum 106 Daily Scrum Sprint Review Sprint Retrospective
Sprint Planning 4 – 8 People Max 8 Hours Max 15 Mins Multiple increments within a Sprint 1 Month Release Increment Stories Planned for a Sprint Sprint Backlog Product Backlog Complete Specs

@arafkarsh arafkarsh Scrum Events 107 Sprints encompass all the work
necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives. SPRINT SPRINT PLANNING Max : 8 Hours 1. Why is Sprint Valuable? 2. What can be Done in this Sprint? 3. How will the chosen work get done? Source: https://www.scrum.org/resources/what-is-scrum DAILY SCRUM Max : 15 mins The Daily Scrum seeks to examine the progress made toward the Sprint Goal and adjust the Sprint Backlog as needed, modifying the planned work for the upcoming period. SPRINT REVIEW During the Sprint Review, the Scrum Team inspects the Sprint's outcome and determines any necessary adaptations for the future. They present their work results to critical stakeholders, and the group discusses progress toward the Product Goal. SPRINT RETROSPECTIVE The Sprint Retrospective aims to plan ways to increase quality and effectiveness.

@arafkarsh arafkarsh Scrum Artifacts 108 PRODUCT BACKLOG The Product Backlog
is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. SPRINT BACKLOG The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum. INCREMENT An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review Source: https://www.scrum.org/resources/what-is-scrum Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact

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

@arafkarsh arafkarsh Rules of Scrum • Sprint Planning meeting is
held at the start of Each Sprint. • Each Sprint must deliver working and fully tested code that demonstrate value to the customer. • Product Owner Prioritizes the Product Backlog. • Team Collectively selects the Amount of Work brought into Sprint • Once a sprint begins, only the team may add to the Sprint backlog. • A Short Scrum meeting is done every day. 110 Source: User Stories Applied by Mike Cohn. Page 204

@arafkarsh arafkarsh Scrum Values 111

@arafkarsh arafkarsh What is Kanban 112 Kanban is a method
for managing the creation of products with an emphasis on • continual delivery (Daily / Hourly) while • not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively. Kanban is a visual management method that was developed by Toyota in the early 1940s. Kanban in Japanese means Card Microsoft Xbox One Team does multiple Daily releases using Kanban.

@arafkarsh arafkarsh Kanban History 113 Introduced by Toyota in Manufacturing
- 1940s It all started in the early 1940s. The first Kanban system was developed by Taiichi Ohno (Industrial Engineer and Businessman) for Toyota automotive in Japan. It was created as a simple planning system, the aim of which was to control and manage work and inventory at every stage of production optimally. Source: https://www.digite.com/kanban/what-is-kanban/ David J. Anderson who was the first to apply the concept to IT, Software development and knowledge work in general in the year 2004.

@arafkarsh arafkarsh Three Principles of Kanban 114 Source: https://resources.collab.net/agile-101/what-is-kanban •
Visualize your current workflow: Seeing all items in the context of one another can provide valuable insights. • Limit work in progress (WIP): This approach helps balance the flow-based method, preventing teams from starting and committing to too much work simultaneously. • Improve flow: When a task is completed, the next highest-priority item from the backlog is pulled into action. To Do In Progress Done

@arafkarsh arafkarsh Kanban Board 115 Backlog Work breakdown Work In
Progress Done Active Done Active Done Track Task blocked due to Dependency. Once the dependent Task is ready, the blocked Task will be moved to Active State. To Do List Max items in WIP must be 1.4x of total Resources A Backlog item is broken down into tasks, and each Task should take at most 1-3 days at max. It's a good practice to keep all the tasks of similar size. Tasks are assigned to respective team members.

@arafkarsh arafkarsh 6 Core Practices in Kanban 116 1. Visualize
the flow of work 2. Limit WIP (Work in Progress) 3. Manage Flow 4. Make Process Policies Explicit 5. Implement Feedback Loops 6. Improve Collaboratively, Evolve Experimentally Source: https://www.digite.com/kanban/what-is-kanban/

@arafkarsh arafkarsh Release Cycles 117 Kanban Preparation Requirements Design Development
Testing Release 1 Day – 1 Weeks Cycle Scrum 1 Month (Max) Cycle 1 or 2 Weeks Cycle also allowed

@arafkarsh arafkarsh Similarities between Kanban and Scrum 118 Task Breakdown
Continuous Improvement Visible Workflow Both Scrum and Kanban supports Large Complex work to be broken down to smaller tasks and completed efficiently. Both place high focus on Continuous Improvement and process optimization and support a highly visible (Task) Workflows for the visibility to all the stake holders.

@arafkarsh arafkarsh Kanban Vs. Scrum 119 Kanban Scrum Roles &
Responsibilities No prescribed roles Pre-defined roles of Scrum master, Product owner and team member Delivery Timelines Continuous Delivery (Daily/Hourly) Time boxed sprints (2-4 Weeks) Delegation & Prioritization Work is pulled through the system (single piece flow) Work is pulled through the system in batches (the sprint backlog) Modifications Changes can be made at any time No changes allowed mid-sprint Measurement of Productivity Cycle time Velocity When to Use? More appropriate in operational environments with a high degree of variability in priority More appropriate in situations where work can be prioritized in batches that can be left alone Source: https://leankit.com/learn/kanban/kanban-vs-scrum/

@arafkarsh arafkarsh Benefits of Kanban 120 • Shorter cycle times
can deliver features faster. • Responsiveness to Change: • When priorities change very frequently, Kanban is ideal. • Balancing demand against throughput guarantees that most the customer-centric features are always being worked. • Requires fewer organization / room set-up changes to get started • Reducing waste and removing activities that don’t add value to the team/department/organization • Rapid feedback loops improve the chances of more motivated, empowered and higher-performing team members

@arafkarsh arafkarsh Agile is Not what you do. Agility is
How you do it. 121

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

@arafkarsh arafkarsh 123 Architecture Styles, Patterns & Design Patterns •
Component-based • Client-server • Event-driven • Layered Architecture • Monolithic application • Plug-ins • Publish-subscribe • Service Based • Service-Oriented • Microservices Architecture Style: 1. How to Organize the Code, 2. Creating high-level modules & layers and how they interact each other. Architecture Patterns: A Recurring solution to a recurring problem. Providing the Solution to an Architecture Style. Ex. How a request is processed from the outer layer to inner layer. • Three Tier • Micro Kernel • Model View Controller • Event Sourcing and CQRS • Domain Driven Design Design Patterns: Scope of the Design Patterns is much narrower compared to an Architecture Pattern. It focuses on instantiating an object, behavior of the object. • Adapter • Builder / Factory • Saga • Repository • Aggregate Root Wider Scope Narrow Scope

@arafkarsh arafkarsh Component Based Architecture 124 1. Logical Units: Breaking
the App into well defined logical units. 2. Communication: Components communicate using a COM/DCOM, EJB, CORBA, RMI and other protocols or standard API contracts. 3. Reusability: A well defined component can be reused and self deployable unit. 4. Maintenance: Easy to change and upgrade the components without affecting the whole system 5. Ease of Development: With well defined API contracts, it’s easy to develop a component to do a specific task without impacting other parts of the system. 6. Ease of Deployment: It is easy to upgrade the existing version of the component with the latest version without impacting other parts of the system (Provided backward compatibility is maintained).

@arafkarsh arafkarsh o A network separates all the 3 Layers,
and by Value, data is transferred. o You can upgrade a layer without worrying about the impact on the other layer as long as the contract between the layers is intact. o The logic Tier can be further divided into 1. Web Services Layer 2. Business Layer 3. Database Layer Layered Architecture Style 125 UI Layer WS BL DL Database Shopping Cart Order Customer Product John J. Donovan developed it in Open Environment Corporation (OEC), a tools company he founded in Cambridge, Massachusetts. 3 Tier Architecture Pattern https://professordonovan.com/open-environment-corporation Presentation Tier UI is the topmost level of the Application. The primary function of the UI is to give a better Human-Machine Interaction. Logic Tier The Logic Tier is the intermediary between the Presentation and Database Tier. Its responsibilities include Interpreting commands, Making logical decisions and evaluations, Performing calculations, and Facilitating the movement and processing of data between the surrounding layers. Database Tier The information is stored and retrieved from the Database Tier. The data is sent back to the Logic Tier for processing and then back to Presentation Tier for the User to take action.

@arafkarsh arafkarsh Service Based Architecture 126 SOA and Microservices based
on Service Based Architecture 1. Distributed Computing: Common thing in Service based architecture is distributed computing. 2. Communication: Services communicate using a Remote Access Protocol (SOAP, REST, RMI, JMS, Message Queues, AMQP (Advanced Message Queuing Protocol) 3. Service Contracts: They are based on XML, JSON, ProtoBuf, etc. Contract versioning is a crucial aspect of contracts and their future evolution. 4. Availability and Responsiveness: Availability ensures that there is no single point of failure and Responsiveness ensures that the Service Responds on time. 5. Security: As Services are independent components, security and access controls must be taken care of. JSON Web Token is a popular standard. 6. Transactions: Transaction management is a Big challenge in Service-based Architecture. 2 Phase Commit, or Saga Design Patterns, focus on addressing these challenges.

@arafkarsh arafkarsh SOA – Service Oriented Architecture 127 UI Layer
Database Shopping Cart Order Customer Product Enterprise Service Bus Messaging REST / SOAP HTTP MOM JMS ODBC / JDBC Translation Web Services XML WSDL Addressing Security Registry Management Producers Shared Database Consumers 3rd Party Apps Smart Pipes Lot of Business logic resides in the Pipe Traditional Monolithic App with SOA Service properties 1. It logically represents a business activity with a specified outcome. 2. Each Service is self-contained. 3. Each Service is a Blackbox to the Service Consumer. 4. A Service can contain other Services too. 5. Service Can be re-used. For Ex Customer Service can be used by multiple Apps. Source: https://dzone.com/articles/service-oriented-architecture-a-dead-simple-explan

@arafkarsh arafkarsh The microkernel architecture pattern consists of two types
of architecture components: 1. a core system and 2. plug-in modules. Application logic is divided between 1. independent plug-in modules 2. and the basic core system, providing 3. extensibility, 4. flexibility, and 5. isolation of application features 6. and custom processing logic Micro Kernel Architecture Pattern 128 Source: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html Plug-In Component Plug-In Component Plug-In Component Core System Plug-In Component Plug-In Component Plug-In Component

@arafkarsh arafkarsh DDD: Bounded Context – Strategic Design 129 •
Bounded Context is a Specific Business Process / Concern. • Components / Modules inside the Bounded Context are context specific. • Multiple Bounded Contexts are linked using Context Mapping. • One Team assigned to a Bounded Context. • Each Bounded Context will have it’s own Source Code Repository. • When the Bounded Context is being developed as a key strategic initiative of your organization, it’s called the Core Domain. • Within a Bounded Context the team must have same language called Ubiquitous language for Spoken and for Design / Code Implementation. Domain Driven Design

@arafkarsh arafkarsh 130 User Journey X Bounded Context Bounded Context
Bounded Context User Journey Y Bounded Context Bounded Context Bounded Context Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Understanding the Bounded Context (DDD) of an E-Commerce Application. Product Context Order Context Cart Context Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Can we carve out another Microservice from the existing Microservices (Product, Order, Cart)? Monolithic Data Models DDD: App User’s Journey & Bounded Context

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

@arafkarsh arafkarsh DDD: Understanding Aggregate Root 132 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

@arafkarsh arafkarsh Event Sourcing Intro 133 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 Event store Single Source of Truth Greg Young

@arafkarsh arafkarsh 134 Event Sourcing & CQRS (Command and Query
Responsibility Segregation) Presentation Tier Logic Tier • Request Validations • Commands / Domain Logic • Data Persistence Database Tier The same Schema is used for both Read and Write. Read Model Write Model Queries (DTOs) Presentation Tier Logic Tier • Request Validations • Commands / Domain Logic • Data Persistence Database Tier Read & Write Schema are different Separate Process Updates the Read DB Write Model Queries (DTOs) Read Model • In traditional data management systems, both commands (updates to the data) and queries (requests for data) are executed against the same entities in a single data repository. • CQRS is a pattern segregating the operations that read data (Queries) from the operations that update data (Commands) using separate interfaces. • CQRS should only be used on specific portions of a system in Bounded Context (in DDD). • CQRS should be used along with Event Sourcing. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx | Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html Axon Framework For Java Java Axon Framework Resource : http://www.axonframework.org CQS: Bertrand Meyer Greg Young

@arafkarsh arafkarsh Distributed Tx: SAGA Design Pattern instead of 2PC
135 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

@arafkarsh arafkarsh Cell based Architecture – Workload 136 Source: Amazon:
Cell Based Architecture Application Load Balancer (ALB) o Acts as the cell’s HTTP/HTTPS entry point. It distributes traffic across multiple compute instances (ECS tasks/containers) registered in one or more target groups. It keeps only healthy targets in rotation via health checks, and supports host/path-based routing, TLS termination, stickiness, and WAF at the edge. ECS (your compute layer) o Runs many tasks for the same service; ALB targets them (often with dynamic port mapping so multiple tasks can share an instance). ECS integrates natively with ALB target groups, and you can use blue/green deployments where CodeDeploy shifts production traffic between old/new task sets behind the ALB. Storage (per-cell state) o A database/cache/queue scoped to the cell for isolation. Typical choices: RDS Multi-AZ for resilient relational storage; ElastiCache/Redis for sessions and hot data (keeping app stateless behind the ALB). Multi-AZ protects against AZ loss; Redis guidance favors scale-out via Sharding when you need throughput. AZ = Availability Zone

@arafkarsh arafkarsh Cell based Architecture – Core Pieces 137 Run
many small, independent replicas of your workload—called cells—and route each request/tenant to exactly one cell. Source: Amazon: What is a Cell Based Architecture? Core pieces o Cell router (data-plane edge): A thin layer that maps a partition key (tenant/shop/user/resource) → a specific cell. Keep the router simple, horizontally scalable, and free of business logic. o Cells: Each is a complete instance of the workload (compute + storage + queues, etc.). No cross-cell state sharing unless absolutely required o Control plane: Admin API(s) to provision/migrate/retire cells, manage placement, and update router mappings.

@arafkarsh arafkarsh CBA— Why it works? 138 o Failure containment:
If 1 of 10 cells dies, ~90% of traffic is unaffected; failures like “poison pill” requests or bad deploys stay inside the cell. o Testability & predictability: You can load test at full cell scale, which is much cheaper than testing the whole fleet. Cells have uniform size, so ops math becomes sane. o Scope-controlled rollouts: Deploy to one cell first, then progressively expand. Boundaries o Cells can be single-AZ (max isolation, more DR work) or multi-AZ/regional (easier to use managed services, but less control over gray failures). Pick based on failure modes and cost. AZ = Availability Zone Source: Amazon: What is a Cell Based Architecture? Cell-based architecture borrows from maritime bulkheads—vertical partitions that divide a ship’s interior into self-contained, watertight compartments. By isolating damage, bulkheads limit flooding and also increase the stiffness of the hull girder.

@arafkarsh arafkarsh Cloud-Native Architecture 139 In short, the microservice architectural
style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. https://martinfowler.com/articles/microservices.html By James Lewis and Martin Fowler Bolo Definition Kya hai? Tell me what’s the definition We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list Microservices definition

@arafkarsh arafkarsh Cloud-Native Architecture 140 Components via Services Organized around
Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Evolutionary Design Source: US DoD DevSecOps Fundamentals Playbook. Page 6 Layered Architecture Domain Driven Design Capability Centric Design Event Based / Kafka / Streams / Connect Epics / User Stories / MVP / DDD / ES & CQRS Data Mesh / K8s/Kafka Clusters / Infra Patterns Containers / Kubernetes / Mesh / Terraform Bulkhead / Circuit Breaker / Blue- Green Deployment Microservices Characteristics

@arafkarsh arafkarsh Evolutionary Design – Minimum Viable Product – 4D
141 Evolutionary Design 1 2 3 4 1 2 3 4 5 Themes / Initiatives / Epics / User Stories / Acceptance Criteria / DDD / ES-CQRS / Agile (Kanban) Iterative development Define Design Develop Monolithic Design Deploy

@arafkarsh arafkarsh API Architecture Maturity Levels 142 Source: https://www.apiscene.io/lifecycle/7-layers-of-api-architecture-maturity/ •
REST & gRPC – API Communication in Microservices: https://www.apiscene.io/lifecycle/rest-grpc-api-communication-in-microservices/ • A Postman API Governance Collection: https://www.apiscene.io/lifecycle/a-postman-api-governance-collection/ • Impact of Distributed Architecture to API Lifecycle: https://www.apiscene.io/lifecycle/what-is-the-impact-of-distributed-architecture-to-api-lifecycle/ •

@arafkarsh arafkarsh Architecture Styles Summary 143 1. Architecture Style 1.
Component Based 2. Client Server 3. Event Driven 4. Layered Architecture 5. Monolithic 6. Pub / Sub Architecture Style 7. Cell Based Architecture 8. Service Based 1. Service Oriented 2. Microservices 2. Architecture Patterns 1. Three Tier 2. Micro Kernel 3. Domain Driven Design 4. Event Sourcing and CQRS 3. Design Patterns 1. Saga 2. Repository 3. Aggregate Root

@arafkarsh arafkarsh MICROSERVICES TECHNOLOGY LANDSCAPE 1999 Commercial Virtual Machine 2003
VM Monitor Hypervisor 2004 Architecture Pattern Domain Driven Design 2006 Cloud Services Amazon AWS 2013 Containers Docker 2014 Container Orchestrator Kubernetes 2005 Architecture Pattern Event Sourcing & CQRS 1995s 2020s 2000s Cloud Native Apps Infrastructure Evolution 1. Virtual Machines 2. Containers 3. Kubernetes (Orchestrator) 4. Istio (Service Mesh) 5. Kafka (Messaging) Architecture Patterns 1. API Gateways / LB 2. Service Discovery 3. Event Driven 4. Service Mesh 5. Domain Driven Design 6. Event Sourcing & CQRS 7. Reactive Programming 8. Distributed Tx 2015 Service Mesh Istio 2011 Messaging Kafka 1998 Architecture Style 3 Tier Architecture 2003 Architecture Style SOA 2020 Service Mesh Open Service Mesh 2007 Linux Kernel cgroups 2008 Cloud Services Google Cloud 2010s 2010 Cloud Services Microsoft Azure 2011 Hybrid Cloud Services RedHat OpenShift 1999 Software Process XP (Agile) 1987 Design Pattern Saga Pattern 2005s 2015s 2004 Software Process Kanban 1985s 2010 Cloud Services OpenStack 2009 PaaS Services Cloud Foundry

@arafkarsh arafkarsh Composable Enterprise Architecture 145 A composable enterprise is
an organisation that delivers business outcomes and adapts to the pace of business change. It does this through the assembly and combination of Packaged Business Capabilities (PBCs). PBCs are application building blocks that have been purchased or developed. Source: Gartner: Future of Applications: Delivering the Composable Enterprise | Why does it matter? APIs Event Channels Composable Enterprise Business Capabilities Business Capabilities Business Ecosystems My Application Experience Digital Business Technology Platform Source: Gartner Future of Applications

@arafkarsh arafkarsh Composable Enterprise Architecture 146 Source: Gartner: Future of
Applications: Delivering the Composable Enterprise | Why does it matter? On Demand Scalability Service & Apps Integrated with Clients & Devices Automated On Demand Services Self Service Options for App & Data MASA Mesh App & Service Architecture Enterprise Data Available, Accessible, & Integrated into Data Flow Delivers > Packaged Business Capabilities

@arafkarsh arafkarsh Cloud Native Architecture 147 Components via Services Organized
around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Evolutionary Design Source: US DoD DevSecOps Fundamentals Playbook. Page 6 Layered Architecture Epics / User Stories / MVP / DDD / ES & CQRS Microservices Characteristics Capability Centric Design

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

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

@arafkarsh arafkarsh Bounded Context – Strategic Design 150 • Bounded
Context is a Specific Business Process / Concern. • Components / Modules inside the Bounded Context are context specific. • Multiple Bounded Contexts are linked using Context Mapping. • One Team assigned to a Bounded Context. • Each Bounded Context will have it’s own Source Code Repository. • When the Bounded Context is being developed as a key strategic initiative of your organization, it’s called the Core Domain. • Within a Bounded Context the team must have same language called Ubiquitous language for Spoken and for Design / Code Implementation.

@arafkarsh arafkarsh DDD: App User’s Journey & Bounded Context 151
An e-Comm App User’s Journey can run across multiple Bounded Context / Microservices. User Journey X Bounded Context Bounded Context Bounded Context User Journey Y Bounded Context Bounded Context Bounded Context Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Understanding Bounded Context (DDD) of a e-Commerce App Product Context Order Context Cart Context Source: Domain-Driven Design Reference by Eric Evans Domain Driven Design Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Can we carve out another Microservice from the existing Microservices?

@arafkarsh arafkarsh DDD: Bounded Context – Strategic Design 152 An
App User’s Journey can run across multiple Bounded Context / Micro Services. Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Understanding Bounded Context (DDD) of a Restaurant App Dinning Context Kitchen Context Menu Context Source: Domain-Driven Design Reference by Eric Evans Areas of the domain treated independently Discovered as you assess requirements and build language Bounded Context Bounded Context Bounded Context User Journey X

@arafkarsh arafkarsh DDD : Understanding Bounded Context Source: Patterns, Principles
and Practices of DDD – Page 124 This model shows multiple responsibilities of the shared Model – Product. This is a classic example of Big Ball of Mud. 153

and Practices of DDD – Page 127 Each of this context will become a Microservice 154

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

@arafkarsh arafkarsh Customer Model in Different Bounded Context 156 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.

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 157

and Practices of DDD – Page 157 Microservice is a Bounded Context 158

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

@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 Data Store Use Case Boundary Bounded Context A • Reduces Technical Debt • Dependency Injection • Auto Wiring 160

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

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

@arafkarsh arafkarsh How? Focus on Core Complexity & Opportunity in
the Domain Explore models in collaboration of Domain Experts & Software Experts Write software that expresses these Models explicitly Speak Ubiquitous Language within a Bounded Context 163 Eric Evans – Explore DDD, Denver, 2017

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

@arafkarsh arafkarsh How? Identity the areas of the business which
is critical for the success of the business. Why are these areas important? Why can't we buy a solution rather than building it? What makes the system worth building it? Core Domain 165 Look at the Core Domain as a Product instead of a Project

@arafkarsh arafkarsh How? Supporting Domains are the domains that helps
the Core Domain. In an E-Commerce application like Amazon or Flipkart, product search functionality is a supporting domain. Even off the shelf application can be used in a supporting domain, For Ex. Ticketing system. Supporting Domains 166

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

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

@arafkarsh arafkarsh Domain Vs. Domain Model 169 Source: Patterns, Principles
and Practices of DDD – Page 43 o Analysis Model or Business Model is to describe the Problem space / Domain. o The Domain Model contains only what is relevant to solve the problem. o Domain Model MUST be free of technical complexities.

@arafkarsh arafkarsh Domain Model 170 A domain Model is not
a particular diagram; it is the idea the diagram intends to convey. - Eric Evans Domain Model: An object of the Domain that incorporates both behaviour and data. - Martin Fowler

@arafkarsh arafkarsh Indicators for Discovering Bounded Context Identify the Business
Capabilities from the User Activities / Stories / Use Cases Based on Activities: If an area within the system contains a set of exclusive activities then that’s an indicator for a Business Capabilities. Based on Trigger: Any area which gets automatically triggered based on external input and does some activities based on that trigger. Ex. Spam Checker, Virus Checker in mail attachments. 171

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

@arafkarsh arafkarsh List Core Activities 173 o List Code Activities
for the Primary Use Case o Identify the Business Function / Capabilities of each of the Activity o Identify the User Role (Actor) for this Activity, o Ensure that the list of the Activities complete the entire Business Solution. Activity Business Function Actor 1 2 3 4 5 6 7 8 9 10

@arafkarsh arafkarsh Summary: User Journey / CCD / Domain Driven
Design 174 User Journey Bounded Context 1 Bounded Context 2 Bounded Context 3 1. Bounded Contexts 2. Entity 3. Value Objects 4. Aggregate Roots 5. Domain Events 6. Repository 7. Service 8. Factory Front-End Back-End Database Business Capability 1 Front-End Back-End Database Business Capability 2 Front-End Back-End Database Business Capability 3 Vertically sliced Product Team Capability Centric Design Domain Expert Analyst Architect QA Design Docs Test Cases Code Developers Domain Driven Design Ubiquitous Language Core Domain Sub Domain Generic Domain

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

@arafkarsh arafkarsh DDD : Understanding Context Map 1. A context
map provides Global View of the system that UML or architecture diagrams completely miss, helping us to focus on choices that are really viable in your scenario without wasting money. 2. Each Bounded Context fits within the Context Map to show how they should communicate amongst each other and how data should be shared. 176 Up Stream (u) – Down Stream (d) The upstream team may succeed independently of the fate of the downstream team. Mutually Dependent Success depends on the success of both the teams. Free In which success or failure of the development work in other contexts has little affect on delivery.

@arafkarsh arafkarsh DDD: Context Map 177 Term Definition Action Partnership
When teams in two context will succeed or fail together, a cooperative relationship often emerges. Forge Partnerships Shared Kernel Sharing a part of the Mode and associated code is very intimate interdependency, which can leverage design work or undermine it. Keep the Kernel Small. Customer / Supplier When two teams are in upstream – downstream relationship, where the upstream team may succeed independently of the fate of the downstream team, the needs of the downstream come to be addressed in a variety of ways with wide range of consequences. Downstream priorities factor into upstream planning. Conformist Upstream has no motivation in this partnership to keep the promise. Altruism may motivate Upstream developers to give promises they cant keep. Share just enough info with upstream to keep their motivation. Anti Corruption Layer When the translation between two bounded context becomes more complex, then the translation layer takes on a more defensive tone. (down stream) creates a layer in sync own model and matching (up stream) functionality.

@arafkarsh arafkarsh DDD: Context Map 178 Term Definition Action Open
Host Service When a subsystem has to be integrated with many others, customizing a translator for each can bog down the team. There is more and more to maintain, and more and more to worry about when changes are made. Use a one of translator to augment the Protocol to share info (REST) Published Language Translation between the models of two bounded contexts requires a common language. Published Language is often combined with Open Host Service. Use a well documented shared language (JSON) Separate Ways If two sets of functionality have no significant relationship, they can be completely cut loose from each other. Integration is always expensive and sometimes the benefit is small. Bounded context with no connection to others. Big Ball of Mud As we survey existing systems, we find that, in fact, there are parts of systems, often large ones, where models are mixed and boundaries are inconsistent. Designate the mess as a Big Ball of Mud.

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

@arafkarsh arafkarsh DDD: Strategic Design Patterns 180 Pattern Description Page
1 Bounded Context They are NOT Modules A Bounded Context delimits the applicability of a particular model so that the team members have a clear and shared understanding of what has to be consistent and how it relates to other Contexts. Contexts can be created from (but not limited to) the following: • how teams are organized • the structure and layout of the code base • usage within a specific part of the domain 335 2 Context Map Context mapping is a design process where the contact points and translations between bounded contexts are explicitly mapped out. Focus on mapping the existing landscape, and deal with the actual transformations later. 1. Shared Kernel 2. Customer / Supplier 3. Conformist 4. Anti Corruption Layer 5. Separate Ways 3 Specification Pattern Use the specification pattern when there is a need to model rules, validation and selection criteria. The specification implementations test whether an object satisfies all the rules of the specification. 4 Strategy Pattern The strategy pattern, also known as the Policy Pattern is used to make algorithms interchangeable. In this pattern, the varying 'part' is factored out. 5 Composite Pattern This is a direct application of the GoF pattern within the domain being modeled. The important point to remember is that the client code should only deal with the abstract type representing the composite element. Page Number from Domain Driven Design – Published in 2015

@arafkarsh arafkarsh Common Problems 181 1. Trying to make a
perfect Boundary for the Context. 2. Overemphasizing the importance of Tactical Design Patterns 3. Using the same architecture for all Bounded Contexts 4. Neglecting the Strategic Design Patterns 5. Focusing on Code rather than the principles of DDD

@arafkarsh arafkarsh Domain Driven Design • Strategic Design • Tactical
Design o Entity o Value Object o Aggregate Root o Factory o Repository o Domain Service o Domain Events 182

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

@arafkarsh arafkarsh Layered Architecture 184 • Explicit Domain Models –
Isolate your models from UI, Business Logic. • Domain Objects – Free of the Responsibility of displaying themselves or storing themselves or managing App Tasks. • Zero Dependency on Infrastructure, UI and Persistent Layers. • Use Dependency Injection for Loosely Coupled Objects. • All the Code for Domain Model in a Single Layer. • Domain Model should be Rich enough to represent Business Knowledge. Source: DDD Reference by Chris Evans Page 17

@arafkarsh arafkarsh Entity 185 Entities are Domain Concepts with Identity
and Continuity and can be stored in a database. Identity Examples of an Entity • Order ID in Order Entity • Social Security Number in Person Entity Entity • Order (Aggregate Root) • Order ID • Order Item Array • Payment • Shipping Address • Order Item • Payment • Total Payment

@arafkarsh arafkarsh Value Objects 186 Value Object • Shipping Address
• Name • Street • City • State • Country • Item Value • Amount • Currency • Audit Log • Time • User • IP Address It Represent a specific business concept related that Bounded Context. Value objects doesn’t have any specific identity. It exists as part of an Entity and stored along with Entity. • Currency • USD • INR EURO • POUND • Order Status • IN PROGRESS • IN TRANSIT • DELIVERED • Payment Type • CREDIT CARD • DEBIT CARD • Record State Embeddable Object Enumeration

@arafkarsh arafkarsh Understanding Aggregate Root 187 Order Customer Shipping Address
Aggregate Root Line Item Line Item Line Item * Payment Strategy Credit Card Cash Bank Transfer Source: Martin Fowler : Aggregate Root • An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. • Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries. • Aggregates are sometimes confused with collection classes (lists, maps, etc.). • Aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain multiple collections, together with simple fields. 125 Domain Driven Design (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA

@arafkarsh arafkarsh Designing and Fine-Tuning Aggregate Root 188 Source :
Effective Aggregate Design Part 1/2/3 : Vaughn Vernon http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf Aggregate Root - #1 Aggregate Root - #2 Super Dense Single Aggregate Root Results in Transaction concurrency issues. Super Dense Aggregate Root is split into 4 different smaller Aggregate Root in the 2nd Iteration. Working on different design models helps the developers to come up with best possible design. (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA

@arafkarsh arafkarsh Rules for Building Aggregate Roots 1. Protect True
Invariants in Consistency Boundaries. This rule has the added implication that you should modify just one Aggregate instance in a single transaction. In other words, when you are designing an Aggregate composition, plan on that representing a transaction boundary. 2. Design Small Aggregates. The smallest Aggregate you can design is one with a single Entity, which will serve as the Aggregate Root. 3. Reference Other Aggregates Only By Identity. 4. Use Eventual Consistency Outside the Consistency Boundary. This means that ONLY ONE Aggregate instance will be required to be updated in a single transaction. All other Aggregate instances that must be updated as a result of any one Aggregate instance update can be updated within some time frame (using a Domain Event). The business should determine the allowable time delay. 5. Build Unidirectional Relationship from the Aggregate Root. 189

@arafkarsh arafkarsh Domain Services 190 Domain Services focuses bringing the
Behavior to your Domain involving Entities and Value Objects. It focuses on a Single Responsibility. Implementation of the Domain Service resides in the service layer (Adapters) and not in the Domain Layer. Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Service Layer

@arafkarsh arafkarsh Domain Events & Integration Events 191 1. Domain
Events represent something happened in a specific Domain. 2. Domain Events should be used to propagate STATE changes across Multiple Aggregates within the Bounded Context. 3. The purpose of Integration Events is to propagate committed transactions and updates to additional subsystems, whether they are other microservices, Bounded Contexts or even external applications. Source: Domain Events : Design and Implementation – Microsoft Docs – May 26, 2017 Domain Data Behavior Order (Aggregate Root) Data Behavior Address (Value Object) Data Behavior OrderItem (Child) 1 n 1 1 Order Created Domain Event Domain Layer Enforce consistency with other Aggregates Event Handler 1 Event Handler n Create and Publish Integration Event to Event Bus. Example: Order Placed Integration Event can be subscribed by Inventory system to update the Inventory details. Event Handler 2

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

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

@arafkarsh arafkarsh Reactive Programming Comparison : Iterable / Streams /
Observable 194 First Class Visitor (Consumer) Serial Operations Parallel Streams (10x Speed) Still On Next, On Complete and On Error are Serial Operations Completely Asynchronous Operations Java 8 – Blocking Call Java 6 – Blocking Call Rx Java - Freedom

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

@arafkarsh arafkarsh Data Transfer Object vs. Value Object 196 Data
Transfer Object Value Object A DTO is just a data container which is used to transport data between layers and tiers. A Value Object represents itself a fix set of data and is similar to a Java enum. It mainly contains of attributes and it’s a serializable object. A Value Object doesn't have any identity, it is entirely identified by its value and is immutable. DTOs are anemic in general and do not contain any business logic. A real world example would be Color.RED, Color.BLUE, Currency.USD Patterns of Enterprise Application Architecture : Martin Fowler http://martinfowler.com/books/eaa.html A small simple object, like money or a date range, whose equality isn’t based on identity. 486 P of EAA Java EE 7 Retired the DTO In Java EE the RS spec became the de-facto standard for remoting, so the implementation of serializable interface is no more required. To transfer data between tiers in Java EE 7 you get the following for FREE! 1. JAXB : Offer JSON / XML serialization for Free. 2. Java API for JSON Processing – Directly serialize part of the Objects into JSON

@arafkarsh arafkarsh DTO – Data Transfer Object • Security Considerations
• Data obtained from untrusted sources, such as user input from a Web page, should be cleansed and validated before being placed into a DTO. Doing so enables you to consider the data in the DTO relatively safe, which simplifies future interactions with the DTO. 197 The Problem Assembler Pattern An object that carries data between processes in order to reduce the number of method calls. Benefits 1. Reduced Number of Calls 2. Improved Performance 3. Hidden Internals 4. Discovery of Business objects Liabilities 1. Class Explosion 2. Additional Computation 3. Additional Coding Effort https://msdn.microsoft.com/en-us/library/ms978717.aspx Problem: How do you preserve the simple semantics of a procedure call interface without being subject to the latency issues inherent in remote communication? The Solution 401 P of EAA

@arafkarsh arafkarsh DTO – Data Transfer Object 198 An object
that carries data between processes in order to reduce the number of method calls. The most misused pattern in the Java Enterprise community is the DTO. DTO was clearly defined as a solution for a distribution problem. DTO was meant to be a coarse-grained data container which efficiently transports data between processes (tiers). On the other hand considering a dedicated DTO layer as an investment, rarely pays off and often lead to over engineered bloated architecture. Real World Java EE Patterns Adam Bien http://realworldpatterns.com Don't underestimate the cost of [using DTOs].... It's significant, and it's painful - perhaps second only to the cost and pain of object- relational mapping. Another argument I've heard is using them in case you want to distribute later. This kind of speculative distribution boundary is what I rail against. Adding remote boundaries adds complexity. One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model. In this case it makes sense to make presentation specific facade/gateway that maps from the domain model and presents an interface that's convenient for the presentation. Patterns of Enterprise Application Architecture : Martin Fowler http://martinfowler.com/books/eaa.html 401 P of EAA

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

@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. 200 Repository Pattern Source: Martin Fowler : http://martinfowler.com/eaaCatalog/repository.html | Microsoft : https://msdn.microsoft.com/en-us/library/ff649690.aspx Mediates between the domain and data mapping layers using a collection- like interface for accessing domain objects. 322 P of EAA Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.

@arafkarsh arafkarsh Anemic Domain Model : Anti Pattern • There
are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. • The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. • The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. • The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. 201 Source: Anemic Domain Model By Martin Fowler : http://martinfowler.com/bliki/AnemicDomainModel.html • lockUser() • unlockUser() • addAddress(String address) • removeAddress(String address)

@arafkarsh arafkarsh Procedural Design Vs. Domain Driven Design 202 1.
Anemic Entity Structure 2. Massive IF Statements 3. Entire Logic resides in Service Layer 4. Type Dependent calculations are done based on conditional checks in Service Layer 4 1 2 3 Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html Domain Driven Design with Java EE 6 By Adam Bien | Javaworld

@arafkarsh arafkarsh Polymorphic Business Logic inside a Domain object 203
Domain Driven Design with Java EE 6 By Adam Bien | Javaworld Computation of the total cost realized inside a rich Persistent Domain Object (PDO) and not inside a service. This simplifies creating very complex business rules. Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html

@arafkarsh arafkarsh Type Specific Computation in a Sub Class 204
Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html We can change the computation of the shipping cost of a Bulky Item without touching the remaining classes. Its easy to introduce a new Sub Class without affecting the computation of the total cost in the Load Class. Domain Driven Design with Java EE 6 By Adam Bien | Javaworld of

@arafkarsh arafkarsh Object Construction : Procedural Way Vs. Builder Pattern
205 Procedural Way Builder Pattern Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html Domain Driven Design with Java EE 6 By Adam Bien | Javaworld

@arafkarsh arafkarsh DDD: Tactical Design Patterns 206 Pattern Description Page
6 Entity An object defined Primarily by its identity is called an Entity 91 - Value Object (Already referred in P of EAA) Many Objects have no conceptual Identity. These objects describe the characteristic of a thing. 97 7 Aggregate Aggregate is a cluster of domain objects that can be treated as a Single Unit. Example Order and Order Item. 125 Aggregate Root An Aggregate will have one of its component object be the Aggregate Root. 127 - Repositories (Already referred in P of EAA) A Repository represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capabilities. Objects of appropriate type are added and removed, and the machinery behind the Repository inserts them or deletes them from the database. This definition gathers a cohesive set of responsibilities for providing access to the roots of Aggregates from early life cycle through the end. 147 8 Factory / Builder Pattern When creation of an Object, or an entire Aggregate, becomes complicated or reveals too much of the internal structure, Factories provides encapsulation. 136 Page Number from Domain Driven Design – Published in 2015

@arafkarsh arafkarsh DDD: Tactical Design Patterns 207 Pattern Description Page
9 Factory / Builder Pattern When creation of an Object, or an entire Aggregate, becomes complicated or reveals too much of the internal structure, Factories provides encapsulation. 136 10 Domain Service A Service tends to be named of an Activity rather than an Entity. 1. The Operation relates to a domain concept that is not a natural part of an Entity. 2. The interface is defined in terms of other elements of the Domain Model 3. The operation is stateless 104 11 Anti – Corruption Layer (External Integration) Creating an isolating layer to provide clients with functionality in terms of their own Domain Model. The layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally the Layer translates in both directions as necessary between the two models. 365 12 Domain Events A Domain Event is a full-fledged part of the Domain Model, a representation of of something that happened in the Domain. Explicit events that the domain experts wants to track and notified of or which are associated with the state changes in other Domain Models. Page Number from Domain Driven Design – Published in 2015

@arafkarsh arafkarsh Shopping Portal Modules – Code Packaging 208 Auth
Products Cart Order Customer Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Packaging Structure Bounded Context Implementation (Repositories, Business Services, Web Services) Domain Models (Entities, Value Objects, DTOs) (Repositories, Business Services, Web Services) Entity Factories Interfaces (Ports)

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

@arafkarsh arafkarsh Shopping Portal 210 Order Context Models Value Object
• Shipping Address • Currency • Item Value • Order Status • Payment Type • Record State • Audit Log Entity • Order (Aggregate Root) • Order Item • Payment DTO • Order • Order Item • Shipping Address • Payment Domain Layer Adapters • Order Repository • Order Service • Order Web Service • Order Query Web Service • Shipping Address Web Service • Payment Web Service Adapters Consists of Actual Implementation of the Ports like Database Access, Web Services API etc. Converters are used to convert an Enum value to a proper Integer value in the Database. For Example, Order Status Complete is mapped to integer value 100 in the database. Services / Ports • Order Repository • Order Service • Order Web Service Utils • Order Factory • Order Status Converter • Record State Converter • Order Query Web Service • Shipping Address Web Service • Payment Web Service

@arafkarsh arafkarsh Summary: User Journey / CCD / Domain Driven
Design 211 User Journey Bounded Context 1 Bounded Context 2 Bounded Context 3 1. Bounded Contexts 2. Entity 3. Value Objects 4. Aggregate Roots 5. Domain Events 6. Repository 7. Service 8. Factory Front-End Back-End Database Business Capability 1 Front-End Back-End Database Business Capability 2 Front-End Back-End Database Business Capability 3 Vertically sliced Product Team Capability Centric Design Domain Expert Analyst Architect QA Design Docs Test Cases Code Developers Domain Driven Design Ubiquitous Language Core Domain Sub Domain Generic Domain

@arafkarsh arafkarsh Cloud Native Architecture 212 Components via Services Organized
around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Evolutionary Design Source: US DoD DevSecOps Fundamentals Playbook. Page 6 Layered Architecture Domain Driven Design Epics / User Stories / MVP / ES & CQRS Microservices Characteristics Capability Centric Design

@arafkarsh arafkarsh APIs in Depth Understanding the API Flow REST
API Standards Open API 3.0 213 4

@arafkarsh arafkarsh SpringBoot MVC 214 Controller @RestController Service @Service Repository
@Repository Model @Entity Data Store Firewall Users DTO @Autowired Service … @Autowired Repository … Dependency Injection Form of IoC Dispatcher Servlet Handler Mapping /cart/customer/{customerId}

@arafkarsh arafkarsh HTTP Response Servlet Request Listener HTTP Request Servlet
Request Listener HTTP Firewall Final Checks on the Response. Integrated into Filter Chain Proxy HTTP Firewall Security checks are performed. Ex. Protocols, Special Chars in URLs API Flow 215 Servlet Filter Chain Servlet Filters. Ex. Log Filter Security Filter Dispatcher Servlet Spring main Front controller Handler Mapping Route request to controller Interceptor Spring Context Pre Handlers Ex. JWT, Rate Limit AOP Before Advice JWT Controller Your Controller Business Service Servlet Filter Chain Servlet Filters. Ex. Add Response Headers Interceptor After Completion Ex. Response Time Calculation View Rendering Renders based on Model View Object Skipped for REST Calls Interceptor Spring Context Post Handlers Ex. Log Data AOP After Advice Controller Your Controller Business Service Servlet Context Spring Context App Context Message Conversion Response Entity Converted to JSON Request Initialized Request Destroyed 1 2 3 4 5 6 7 8

@arafkarsh arafkarsh 1. Servlet Request Listener 216

@arafkarsh arafkarsh 2. Http Firewall 217 HttpFirewall is integrated into
the FilterChainProxy, one of the first elements to handle an incoming HTTP request.

@arafkarsh arafkarsh 3. Servlet Filter Chain 218

@arafkarsh arafkarsh 6. Interceptor 219

@arafkarsh arafkarsh 7. Spring AOP 220

@arafkarsh arafkarsh 8. Rest Controller 221

@arafkarsh arafkarsh 9. Business Service 222

@arafkarsh arafkarsh 10. Repository 223

@arafkarsh arafkarsh REST API Standards o Guidelines o Query Examples
o API Versioning 224

@arafkarsh arafkarsh REST Architecture 225 Source: Roy Fielding's PhD dissertation,
titled "Architectural Styles and the Design of Network-based Software Architectures. Chapter 5 REpresentational State Transfer 1. Client-Server Architecture REST is based on the separation of concerns between the client (the user interface and client-side logic) and the server (the data storage and server-side logic). This separation allows the client and server to evolve independently, improving the scalability and portability of the user interface across multiple platforms. 2. Statelessness Each request from the client to the server must contain all the information necessary to understand and complete the request. The server should not store any client context between requests. This statelessness ensures that each request can be treated independently, which increases reliability and scalability but may reduce efficiency in some cases where state information must be transferred with each request. 3. Cacheability Responses must, implicitly or explicitly, define themselves as cacheable or non-cacheable. If a response is cacheable, the client cache is given the right to reuse that response data for later, equivalent requests. Cacheability can reduce the need for some client-server interactions, improving efficiency, scalability, and user-perceived performance.

titled "Architectural Styles and the Design of Network-based Software Architectures. Chapter 5 REpresentational State Transfer 4. Layered System A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers can improve system scalability by enabling load balancing and shared caches. They can also enforce security policies. 5. Code on Demand (optional) Servers can temporarily extend or customize the functionality of a client by transferring executable code. Examples include compiled components, scripts, or applets. This is an optional constraint, and it enables clients to support new features by downloading code from the server, though it can compromise security.

titled "Architectural Styles and the Design of Network-based Software Architectures. Chapter 5 REpresentational State Transfer 6. Uniform Interface The uniform interface between clients and servers is a fundamental aspect that differentiates REST from other network architectures. This interface simplifies and decouples the architecture, allowing each part to evolve independently. The uniform interface is defined by four constraints: 1. Resource Identification in Requests: Individual resources are identified in requests, using URIs in Web- based REST systems. 2. Resource Manipulation through Representations: When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so. 3. Self-descriptive Messages: Each message includes enough information to describe how to process the message. 4. Hypermedia as the Engine of Application State (HATEOAS): Clients deliver state via body contents, query-string parameters, request headers, and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. This is often simplified to the principle that clients interact with a network application entirely through hypermedia provided dynamically by application servers.

@arafkarsh arafkarsh RESTful Guidelines 228 1. Endpoints as nouns, NOT
verbs Ex. /catalogues /orders /catalogues/products and NOT /getProducts/ /updateProducts/ 2. Use plurals Ex. /catalogues/{catalogueId} and NOT /catalogue/{catalogueId} 3. Documenting 4. Paging 5. Use SSL 6. HTTP Methods GET / POST / PUT / DELETE / OPTIONS / HEAD 7. HTTP Status Codes (Effective usage) 8. Versioning Media Type Version GET /account/5555 HTTP/1.1 Accept: application/vnd.catalogues.v1+json URL path version https://domain/v1/catalogues/products

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

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

@arafkarsh arafkarsh 231 # Name * Who Uses Pros Cons
1 Media Type Versioning Accept: Application/vnd.api.article+xml; version=1.0 Med GitHub • Version Directly @ resource level • Preserve URI • Close to RESTful Specs • Harder to Test • Distort HTTP Headers purpose • Tools required for testing 2 Custom Headers Versioning X-API-Version: 2. Med Microsoft • Preservers URI • Harder to Test • Tools required for testing 3 URI Versioning api.example.com/v1/resource High Google Twitter Amazon • Most common method • Versions can be explored using Browser • Easy to use • Disrupts RESTful Compliance. URI should represent resource and not versions 4 Domain Versioning apiv1.example.com/resource Low Facebook • Same as are URI Versioning • Same as URI Versioning 5 Request Parameter Versioning GET /something/?version=0.1 High Pivotal NetFlix • Similar to URI versioning • It can get messy 6 Date Versioning First request saves the date. Low Clearbit • New APIs can be shipped without changing the end points • Complex to implement • Traceability is difficult. API Versioning

@arafkarsh arafkarsh Open API 3.0 232

@arafkarsh arafkarsh 233

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

@arafkarsh arafkarsh Open API 3.0 Setup in Spring Boot App
235

236

237

@arafkarsh arafkarsh Open API 3.0 Documentation Example GET / 238

@arafkarsh arafkarsh Open API 3.0 Documentation Example POST / 239

@arafkarsh arafkarsh Open API 3.0 Documentation Example PUT / 240

@arafkarsh arafkarsh Open API 3.0 Documentation Example DELETE / 241

@arafkarsh arafkarsh RESTful API Summary 242 o Stateless Architecture o
Endpoints as Nouns, not VERBS o /catalogues, /orders, /products/category o API Versioning o Use the best suited to your environment o Use all the HTTP Verbs o GET, POST, PUT, DELETE

@arafkarsh arafkarsh 243 100s Microservices 1,000s Releases / Day 10,000s
Virtual Machines 100K+ User actions / Second 81 M Customers Globally 1 B Time series Metrics 10 B Hours of video streaming every quarter Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM 10s OPs Engineers 0 NOC 0 Data Centers So what do NetFlix think about DevOps? No DevOps Don’t do lot of Process / Procedures Freedom for Developers & be Accountable Trust people you Hire No Controls / Silos / Walls / Fences Ownership – You Build it, You Run it.

@arafkarsh arafkarsh 244 50M Paid Subscribers 100M Active Users 60
Countries Cross Functional Team Full, End to End ownership of features Autonomous 1000+ Microservices Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf 1000+ Tech Employees 120+ Teams

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

@arafkarsh arafkarsh 246 Thank you DREAM EMPOWER AUTOMATE MOTIVATE India:
+91.999.545.8627 https://arafkarsh.medium.com/ https://speakerdeck.com/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.slideshare.net/arafkarsh http://www.arafkarsh.com/ @arafkarsh arafkarsh LinkedIn arafkarsh.com Medium.com Speakerdeck.com

@arafkarsh arafkarsh 247 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source:
https://github.com/arafkarsh

@arafkarsh arafkarsh 248 Slides: https://speakerdeck.com/arafkarsh

@arafkarsh arafkarsh References 249 Design Thinking 1. What’s Design Thinking:
2020, Feb 4, https://www.youtube.com/watch?v=gHGN6hs2gZY 2. Design Thinking Process: 2017 Oct 23, https://www.youtube.com/watch?v=_r0VX-aU_T8 3. Design Thinking Workshop with Justin Ferrell of Stanford: 2013, Dec 20, https://www.youtube.com/watch?v=Z4gAugRGpeY Lean Startup 1. Lean Startup: Eric Ries, Talks @ Google: https://www.youtube.com/watch?v=fEvKo90qBns 2. Lean, Agile, Design Thinking: https://www.youtube.com/watch?v=OCL6RkUOShI 3. Jeff Gothelf : Lean vs Agile vs Design Thinking: https://www.youtube.com/watch?v=_4VPfmtwRac 4. Lean Startup Summary: Eric Ries, https://www.youtube.com/watch?v=RSaIOCHbuYw

@arafkarsh arafkarsh References 250 1. July 15, 2015 – Agile
is Dead : GoTo 2015 By Dave Thomas 2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google 3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head 4. Feb 17, 2019 - Lean vs Agile vs Design Thinking 5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban 6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained. Agile Methodologies

@arafkarsh arafkarsh References 251 1. Vmware: What is Cloud Architecture?
2. Redhat: What is Cloud Architecture? 3. Cloud Computing Architecture 4. Cloud Adoption Essentials: 5. Google: Hybrid and Multi Cloud 6. IBM: Hybrid Cloud Architecture Intro 7. IBM: Hybrid Cloud Architecture: Part 1 8. IBM: Hybrid Cloud Architecture: Part 2 9. Cloud Computing Basics: IaaS, PaaS, SaaS 1. IBM: IaaS Explained 2. IBM: PaaS Explained 3. IBM: SaaS Explained 4. IBM: FaaS Explained 5. IBM: What is Hypervisor? Cloud Architecture

@arafkarsh arafkarsh References 252 Microservices 1. Microservices Definition by Martin
Fowler 2. When to use Microservices By Martin Fowler 3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler 4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern 5. Thought Works: Microservices in a Nutshell 6. Microservices Prerequisites 7. What do you mean by Event Driven? 8. Understanding Event Driven Design Patterns for Microservices

@arafkarsh arafkarsh References – Microservices – Videos 253 1. Martin
Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 4. GOTO 2015 – Challenges Implementing Micro Services By Fred George 5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 17. GOTO 2017 – Microservices without Servers. By Glynn Bird.

@arafkarsh arafkarsh References 254 Domain Driven Design 1. Oct 27,
2012 What I have learned about DDD Since the book. By Eric Evans 2. Mar 19, 2013 Domain Driven Design By Eric Evans 3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune 8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans 9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans 10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner

@arafkarsh arafkarsh References 255 Event Sourcing and CQRS 1. IBM:
Event Driven Architecture – Mar 21, 2021 2. Martin Fowler: Event Driven Architecture – GOTO 2017 3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016 4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS 6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes

@arafkarsh arafkarsh References 256 Kafka 1. Understanding Kafka 2. Understanding
RabbitMQ 3. IBM: Apache Kafka – Sept 18, 2020 4. Confluent: Apache Kafka Fundamentals – April 25, 2020 5. Confluent: How Kafka Works – Aug 25, 2020 6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020 7. Kafka Streams – Sept 4, 2021 8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018 9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019

@arafkarsh arafkarsh References 257 Databases: Big Data / Cloud Databases
1. Google: How to Choose the right database? 2. AWS: Choosing the right Database 3. IBM: NoSQL Vs. SQL 4. A Guide to NoSQL Databases 5. How does NoSQL Databases Work? 6. What is Better? SQL or NoSQL? 7. What is DBaaS? 8. NoSQL Concepts 9. Key Value Databases 10. Document Databases 11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends 12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012 13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB 14. Oct 30, 2020 - Column vs Row Oriented Databases Explained 15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained! 1. Graph Databases 2. Column Databases 3. Row Vs. Column Oriented Databases 4. Database Indexing Explained 5. MongoDB Indexing 6. AWS: DynamoDB Global Indexing 7. AWS: DynamoDB Local Indexing 8. Google Cloud Spanner 9. AWS: DynamoDB Design Patterns 10. Cloud Provider Database Comparisons 11. CockroachDB: When to use a Cloud DB?

@arafkarsh arafkarsh References 258 Docker / Kubernetes / Istio 1.
IBM: Virtual Machines and Containers 2. IBM: What is a Hypervisor? 3. IBM: Docker Vs. Kubernetes 4. IBM: Containerization Explained 5. IBM: Kubernetes Explained 6. IBM: Kubernetes Ingress in 5 Minutes 7. Microsoft: How Service Mesh works in Kubernetes 8. IBM: Istio Service Mesh Explained 9. IBM: Kubernetes and OpenShift 10. IBM: Kubernetes Operators 11. 10 Consideration for Kubernetes Deployments Istio – Metrics 1. Istio – Metrics 2. Monitoring Istio Mesh with Grafana 3. Visualize your Istio Service Mesh 4. Security and Monitoring with Istio 5. Observing Services using Prometheus, Grafana, Kiali 6. Istio Cookbook: Kiali Recipe 7. Kubernetes: Open Telemetry 8. Open Telemetry 9. How Prometheus works 10. IBM: Observability vs. Monitoring

@arafkarsh arafkarsh References 259 1. Feb 6, 2020 – An
introduction to TDD 2. Aug 14, 2019 – Component Software Testing 3. May 30, 2020 – What is Component Testing? 4. Apr 23, 2013 – Component Test By Martin Fowler 5. Jan 12, 2011 – Contract Testing By Martin Fowler 6. Jan 16, 2018 – Integration Testing By Martin Fowler 7. Testing Strategies in Microservices Architecture 8. Practical Test Pyramid By Ham Vocke Testing – TDD / BDD

@arafkarsh arafkarsh 260 1. Simoorg : LinkedIn’s own failure inducer
framework. It was designed to be easy to extend and most of the important components are plug‐ gable. 2. Pumba : A chaos testing and network emulation tool for Docker. 3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH- managed environment, as an aid to resilience testing of high-availability systems. 4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours. 5. Blockade : Docker-based utility for testing network failures and partitions in distributed applications. 6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server. 7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift components like Pods or Deployment Configs and randomly terminates them. 8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS deployed to an Azure Resource Manager-based resource group. 9. Tugbot : Testing in Production (TiP) framework for Docker. Testing tools

@arafkarsh arafkarsh References 261 CI / CD 1. What is
Continuous Integration? 2. What is Continuous Delivery? 3. CI / CD Pipeline 4. What is CI / CD Pipeline? 5. CI / CD Explained 6. CI / CD Pipeline using Java Example Part 1 7. CI / CD Pipeline using Ansible Part 2 8. Declarative Pipeline vs Scripted Pipeline 9. Complete Jenkins Pipeline Tutorial 10. Common Pipeline Mistakes 11. CI / CD for a Docker Application

@arafkarsh arafkarsh References 262 DevOps 1. IBM: What is DevOps?
2. IBM: Cloud Native DevOps Explained 3. IBM: Application Transformation 4. IBM: Virtualization Explained 5. What is DevOps? Easy Way 6. DevOps?! How to become a DevOps Engineer??? 7. Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg 8. NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM 9. DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk 10. SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE 11. DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU 12. SRE @ Google: https://www.youtube.com/watch?v=d2wn_E1jxn4

@arafkarsh arafkarsh References 263 1. Lewis, James, and Martin Fowler.
“Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Zuul Edge Server, Ketan Gote, May 22, 2017 10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017 11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017 12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017 13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016 15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015

@arafkarsh arafkarsh References 264 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

Agile, User Stories, Domain Driven Design

Agile, User Stories, Domain Driven Design

More Decks by Araf Karsh Hamid

Other Decks in Technology

Featured

Transcript