Agile, User Stories, Domain Driven Design

Slide 1

Slide 1 text

@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 Agile (Scrum/Kanban) / Epics / User Stories Architecture Styles 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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

@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

Slide 5

Slide 5 text

@arafkarsh arafkarsh Agile Scrum (4-6 Weeks) Developer Journey Monolithic Domain Driven Design Event Sourcing and CQRS Waterfall Optional Design Patterns Continuous Integration (CI) 6/12 Months Enterprise Service Bus Relational Database [SQL] / NoSQL Development QA / QC Ops 5 Microservices Domain Driven Design Event Sourcing and CQRS Scrum / Kanban (1-5 Days) Mandatory Design Patterns Infrastructure Design Patterns CI DevOps Event Streaming / Replicated Logs SQL NoSQL CD Container Orchestrator Service Mesh

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

@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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

@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

Slide 11

Slide 11 text

@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

Slide 12

Slide 12 text

@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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

@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

Slide 16

Slide 16 text

@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

Slide 17

Slide 17 text

@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

Slide 18

Slide 18 text

@arafkarsh arafkarsh 18

Slide 19

Slide 19 text

@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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

@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

Slide 22

Slide 22 text

@arafkarsh arafkarsh Business Solution & Business Process 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. ❑ A specific Microservice functionality will be focused on a Business Process / Concern. ❑ Business Processes can be divided further into Business Functions

Slide 23

Slide 23 text

@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 Business Function

Slide 24

Slide 24 text

@arafkarsh arafkarsh Business Solution & Business Process 24 Business Solution: Customer Dining Experience Order Payment Food Menu Kitchen Dining Browse Menu Order Dinner Dinner Served Get Bill Make Payment User Journey with Story Map Business Solution: User Shopping Experience Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search

Slide 25

Slide 25 text

@arafkarsh arafkarsh Business Capability Centric Design 25 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

Slide 26

Slide 26 text

@arafkarsh arafkarsh From Project Based Activity Oriented To Product Based Outcome Oriented Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html 26 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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

@arafkarsh arafkarsh User Story 28 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

Slide 29

Slide 29 text

@arafkarsh arafkarsh Acceptance Criteria / Behavior Driven Development 29 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.

Slide 30

Slide 30 text

@arafkarsh arafkarsh INVEST in Good Stories 30 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.

Slide 31

Slide 31 text

@arafkarsh arafkarsh 3 C’s of User Stories 31 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.

Slide 32

Slide 32 text

@arafkarsh arafkarsh User Stories – Small Stories 32 • 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

Slide 33

Slide 33 text

@arafkarsh arafkarsh Features of BDD 33 • 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.

Slide 34

Slide 34 text

@arafkarsh arafkarsh User Story / Behavior Driven Development 34 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

Slide 35

Slide 35 text

@arafkarsh arafkarsh Estimate – Story Points / Velocity 35 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.

Slide 36

Slide 36 text

@arafkarsh arafkarsh Planning – MoSCoW Rules 36 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

Slide 37

Slide 37 text

@arafkarsh arafkarsh Story Anti-Patterns 37 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

Slide 38

Slide 38 text

@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. 38 Source: User Stories Applied by Mike Cohn. Page 178

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

@arafkarsh arafkarsh Non-Functional Requirements 41 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.

Slide 42

Slide 42 text

@arafkarsh arafkarsh Non-Functional Requirements 42 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.

Slide 43

Slide 43 text

@arafkarsh arafkarsh Non-Functional Requirements 43 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.

Slide 44

Slide 44 text

@arafkarsh arafkarsh Non-Functional Requirements 44 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.

Slide 45

Slide 45 text

@arafkarsh arafkarsh Non-Functional Requirements 45 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.

Slide 46

Slide 46 text

@arafkarsh arafkarsh Non-Functional Requirements 46 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.

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

@arafkarsh arafkarsh Example 1: eCommerce / Checkout Experience 48 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

Slide 49

Slide 49 text

@arafkarsh arafkarsh Example 2: SCM / Inventory Streamlining 49 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

Slide 50

Slide 50 text

@arafkarsh arafkarsh Example 3: Space Shuttle Launch 50 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

Slide 51

Slide 51 text

@arafkarsh arafkarsh Example 4: Manufacturing & Supply Chain 51 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

Slide 52

Slide 52 text

@arafkarsh arafkarsh Example 5: Healthcare App 52 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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

@arafkarsh arafkarsh Example 6: Digital Banking Platform 54 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

Slide 55

Slide 55 text

@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

Slide 56

Slide 56 text

@arafkarsh arafkarsh Epic – Customer Account Management 56 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.

Slide 57

Slide 57 text

@arafkarsh arafkarsh Epic – Receiver Account Management 57 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/-

Slide 58

Slide 58 text

@arafkarsh arafkarsh Epic – Transaction Management 58 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.

Slide 59

Slide 59 text

@arafkarsh arafkarsh Example 7: eCommerce Portal / Shop Easy 59 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

Slide 60

Slide 60 text

@arafkarsh arafkarsh User Journey with Story Map 60 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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

@arafkarsh arafkarsh Shopping Portal – Architects View User Journey 62

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

@arafkarsh arafkarsh Stories – Customer Registration User Journey 65

Slide 66

Slide 66 text

@arafkarsh arafkarsh Epic – Customer 66 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.

Slide 67

Slide 67 text

@arafkarsh arafkarsh Epic – Auth 67 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.

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

@arafkarsh arafkarsh Epic – Search (Product) 69 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.

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

@arafkarsh arafkarsh Epic – Shopping Cart 72 As a Consumer I want to see all the items in the Cart So that I can buy the Product Role-Feature-Reason Matrix User Story – 2 : Show Cart BDD Acceptance Criteria – 1: Show Cart Given The user logged into the portal. When The user then clicks Cart. Then The system retrieves all the Cart Items from the DB and shows in the UI the following details Product Item Name, Thumb scale picture, Quantity, Price, and Delete Button to delete the item and Sum total of Items and Price. IF the Cart is empty (No Records in the DB), then it shows an Empty Cart with the message "Cart is Empty." BDD Acceptance Criteria – 2: Show Cart Given The Request is authenticated. When The Input contains the user login id. Then The system retrieves all the Cart Items from the DB and shows in the UI the following details. Product Item Name, Thumb scale picture, Quantity, Price IF the Cart is empty (No Records in the DB), then it shows an Empty Cart with the message “Cart is Empty."

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

@arafkarsh arafkarsh Epic – Customer 74 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.

Slide 75

Slide 75 text

@arafkarsh arafkarsh Epic – Order : Credit Card 75 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.

Slide 76

Slide 76 text

@arafkarsh arafkarsh Epic – Payment 76 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.

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

@arafkarsh arafkarsh Epic – Auth 78 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.

Slide 79

Slide 79 text

@arafkarsh arafkarsh Epic – Search (Product: Price Range) 79 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.

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

@arafkarsh arafkarsh Epic – Order : PayPal 82 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.

Slide 83

Slide 83 text

@arafkarsh arafkarsh 83 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!

Slide 84

Slide 84 text

@arafkarsh arafkarsh Summary: Business Capability Centric Design 84 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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

@arafkarsh arafkarsh Agile Values 86 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

Slide 87

Slide 87 text

@arafkarsh arafkarsh Scrum 87 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

Slide 88

Slide 88 text

@arafkarsh arafkarsh Scrum Events 88 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.

Slide 89

Slide 89 text

@arafkarsh arafkarsh Scrum Artifacts 89 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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

@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. 91 Source: User Stories Applied by Mike Cohn. Page 204

Slide 92

Slide 92 text

@arafkarsh arafkarsh Scrum Values 92

Slide 93

Slide 93 text

@arafkarsh arafkarsh What is Kanban 93 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.

Slide 94

Slide 94 text

@arafkarsh arafkarsh Kanban History 94 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.

Slide 95

Slide 95 text

@arafkarsh arafkarsh Three Principles of Kanban 95 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

Slide 96

Slide 96 text

@arafkarsh arafkarsh Kanban Board 96 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.

Slide 97

Slide 97 text

@arafkarsh arafkarsh 6 Core Practices in Kanban 97 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/

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

@arafkarsh arafkarsh Similarities between Kanban and Scrum 99 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.

Slide 100

Slide 100 text

@arafkarsh arafkarsh Kanban Vs. Scrum 100 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/

Slide 101

Slide 101 text

@arafkarsh arafkarsh Benefits of Kanban 101 • 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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

@arafkarsh arafkarsh Component Based Architecture 105 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).

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

@arafkarsh arafkarsh Service Based Architecture 107 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.

Slide 108

Slide 108 text

@arafkarsh arafkarsh SOA – Service Oriented Architecture 108 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

Slide 109

Slide 109 text

@arafkarsh arafkarsh Microservices definition 109 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

Slide 110

Slide 110 text

@arafkarsh arafkarsh Microservices Characteristics 110 We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Evolutionary Design Source: US DoD DevSecOps Fundamentals Playbook. Page 6

Slide 111

Slide 111 text

@arafkarsh arafkarsh Evolutionary Design 111 Design Development Evolutionary Design Monolithic Design 1 2 3 4 1 2 3 4 5 Epics / Initiatives / User Stories / Acceptance Criteria, Agile (Kanban) Iterative development

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

@arafkarsh arafkarsh DDD: Bounded Context – Strategic Design 113 • 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

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

@arafkarsh arafkarsh Event Sourcing Intro 117 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

Slide 118

Slide 118 text

@arafkarsh arafkarsh 118 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

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

@arafkarsh arafkarsh API Architecture Maturity Levels 120 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/ •

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

@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

Slide 123

Slide 123 text

@arafkarsh arafkarsh Composable Enterprise Architecture 123 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

Slide 124

Slide 124 text

@arafkarsh arafkarsh Composable Enterprise Architecture 124 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

Slide 125

Slide 125 text

@arafkarsh arafkarsh Cloud Native Architecture 125 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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

@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 127 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

Slide 128

Slide 128 text

@arafkarsh arafkarsh Bounded Context – Strategic Design 128 • 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.

Slide 129

Slide 129 text

@arafkarsh arafkarsh DDD: App User’s Journey & Bounded Context 129 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?

Slide 130

Slide 130 text

@arafkarsh arafkarsh DDD: Bounded Context – Strategic Design 130 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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

@arafkarsh arafkarsh DDD : Understanding Bounded Context Source: Patterns, Principles and Practices of DDD – Page 132 Each of this Bounded Context will become a Microservice Communication across Bounded Context Source: Patterns, Principles and Practices of DDD – Page 203 135

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

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

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

@arafkarsh arafkarsh Domain Vs. Domain Model 147 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.

Slide 148

Slide 148 text

@arafkarsh arafkarsh Domain Model 148 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

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

@arafkarsh arafkarsh List Core Activities 151 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

Slide 152

Slide 152 text

@arafkarsh arafkarsh Summary: User Journey / CCD / Domain Driven Design 152 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

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

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

Slide 155

Slide 155 text

@arafkarsh arafkarsh DDD: Context Map 155 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.

Slide 156

Slide 156 text

@arafkarsh arafkarsh DDD: Context Map 156 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.

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

@arafkarsh arafkarsh DDD: Strategic Design Patterns 158 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

Slide 159

Slide 159 text

@arafkarsh arafkarsh Common Problems 159 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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

@arafkarsh arafkarsh Layered Architecture 162 • 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

Slide 163

Slide 163 text

@arafkarsh arafkarsh Entity 163 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

Slide 164

Slide 164 text

@arafkarsh arafkarsh Value Objects 164 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

Slide 165

Slide 165 text

@arafkarsh arafkarsh Understanding Aggregate Root 165 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

Slide 166

Slide 166 text

@arafkarsh arafkarsh Designing and Fine-Tuning Aggregate Root 166 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

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

@arafkarsh arafkarsh Domain Services 168 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

Slide 169

Slide 169 text

@arafkarsh arafkarsh Domain Events & Integration Events 169 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

Slide 170

Slide 170 text

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

Slide 171

Slide 171 text

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

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

@arafkarsh arafkarsh Data Transfer Object vs. Value Object 174 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

Slide 175

Slide 175 text

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

Slide 176

Slide 176 text

@arafkarsh arafkarsh DTO – Data Transfer Object 176 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

Slide 177

Slide 177 text

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

Slide 178

Slide 178 text

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

Slide 179

Slide 179 text

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

Slide 180

Slide 180 text

@arafkarsh arafkarsh Procedural Design Vs. Domain Driven Design 180 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

Slide 181

Slide 181 text

@arafkarsh arafkarsh Polymorphic Business Logic inside a Domain object 181 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

Slide 182

Slide 182 text

@arafkarsh arafkarsh Type Specific Computation in a Sub Class 182 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

Slide 183

Slide 183 text

@arafkarsh arafkarsh Object Construction : Procedural Way Vs. Builder Pattern 183 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

Slide 184

Slide 184 text

@arafkarsh arafkarsh DDD: Tactical Design Patterns 184 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

Slide 185

Slide 185 text

@arafkarsh arafkarsh DDD: Tactical Design Patterns 185 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

Slide 186

Slide 186 text

@arafkarsh arafkarsh Shopping Portal Modules – Code Packaging 186 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)

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

@arafkarsh arafkarsh Shopping Portal 188 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

Slide 189

Slide 189 text

@arafkarsh arafkarsh Summary: User Journey / CCD / Domain Driven Design 189 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

Slide 190

Slide 190 text

@arafkarsh arafkarsh Cloud Native Architecture 190 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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

@arafkarsh arafkarsh SpringBoot MVC 192 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}

Slide 193

Slide 193 text

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

Slide 194

Slide 194 text

@arafkarsh arafkarsh 1. Servlet Request Listener 194

Slide 195

Slide 195 text

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

Slide 196

Slide 196 text

@arafkarsh arafkarsh 3. Servlet Filter Chain 196

Slide 197

Slide 197 text

@arafkarsh arafkarsh 6. Interceptor 197

Slide 198

Slide 198 text

@arafkarsh arafkarsh 7. Spring AOP 198

Slide 199

Slide 199 text

@arafkarsh arafkarsh 8. Rest Controller 199

Slide 200

Slide 200 text

@arafkarsh arafkarsh 9. Business Service 200

Slide 201

Slide 201 text

@arafkarsh arafkarsh 10. Repository 201

Slide 202

Slide 202 text

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

Slide 203

Slide 203 text

@arafkarsh arafkarsh REST Architecture 203 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.

Slide 204

Slide 204 text

@arafkarsh arafkarsh REST Architecture 204 Source: Roy Fielding's PhD dissertation, 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.

Slide 205

Slide 205 text

@arafkarsh arafkarsh REST Architecture 205 Source: Roy Fielding's PhD dissertation, 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.

Slide 206

Slide 206 text

@arafkarsh arafkarsh RESTful Guidelines 206 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

Slide 207

Slide 207 text

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

Slide 208

Slide 208 text

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

Slide 209

Slide 209 text

@arafkarsh arafkarsh 209 # 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

Slide 210

Slide 210 text

@arafkarsh arafkarsh Open API 3.0 210

Slide 211

Slide 211 text

@arafkarsh arafkarsh 211

Slide 212

Slide 212 text

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

Slide 213

Slide 213 text

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

Slide 214

Slide 214 text

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

Slide 215

Slide 215 text

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

Slide 216

Slide 216 text

@arafkarsh arafkarsh Open API 3.0 Documentation Example GET / 216

Slide 217

Slide 217 text

@arafkarsh arafkarsh Open API 3.0 Documentation Example POST / 217

Slide 218

Slide 218 text

@arafkarsh arafkarsh Open API 3.0 Documentation Example PUT / 218

Slide 219

Slide 219 text

@arafkarsh arafkarsh Open API 3.0 Documentation Example DELETE / 219

Slide 220

Slide 220 text

@arafkarsh arafkarsh RESTful API Summary 220 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

Slide 221

Slide 221 text

@arafkarsh arafkarsh 221 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.

Slide 222

Slide 222 text

@arafkarsh arafkarsh 222 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

Slide 223

Slide 223 text

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

Slide 224

Slide 224 text

@arafkarsh arafkarsh 224 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

Slide 225

Slide 225 text

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

Slide 226

Slide 226 text

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

Slide 227

Slide 227 text

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

Slide 228

Slide 228 text

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

Slide 229

Slide 229 text

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

Slide 230

Slide 230 text

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

Slide 231

Slide 231 text

@arafkarsh arafkarsh References – Microservices – Videos 231 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.

Slide 232

Slide 232 text

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

Slide 233

Slide 233 text

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

Slide 234

Slide 234 text

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

Slide 235

Slide 235 text

@arafkarsh arafkarsh References 235 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?

Slide 236

Slide 236 text

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

Slide 237

Slide 237 text

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

Slide 238

Slide 238 text

@arafkarsh arafkarsh 238 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

Slide 239

Slide 239 text

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

Slide 240

Slide 240 text

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

Slide 241

Slide 241 text

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

Slide 242

Slide 242 text

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