Agile, User Stories, Domain Driven Design

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

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

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

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

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

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

@arafkarsh arafkarsh Design Thinking 8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@arafkarsh arafkarsh ShopEasy – eCommerce Portal Theme Epic User Story Sprint ShopEasy – eCommerce Application 1. Customer Management 2. Search Product 3. Catalogue 4. Shopping Cart 5. Order Processing 6. Payments 2. Search Product Release 1 1. Global Search Release 2 1. Search by Brand 2. Search by Price Range Release 3 1. Search by Model 2. Search by Rating Stories 1. Global Search 2. Search by Brand 3. Search by Price Range 4. Search by Model 5. Search by Rating 33

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

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

@arafkarsh arafkarsh Shopping Portal – Architects View User Journey 36

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

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

@arafkarsh arafkarsh Stories – Customer Registration User Journey 39

@arafkarsh arafkarsh Epic – Customer 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 User enters values in the fields First Name, Last Name, DOB Address, Email Address, Phone No. Then If the following fields contains values First Name, Last Name, Address, Email Address and Phone No. AND Age is greater than 18 Save the Data. BDD Acceptance Criteria – 2 : Generate Password Given User Info Available When Email Address is a valid email Then Generate the password AND Send mail with user email address as login id the URL of the portal AND Send Password in a separate email address. AND Store data on mail status as mail send or failed. BDD Acceptance Criteria – 3 : Resend Mail Given User Registration mail status is available When The Mail status is failed. Then Send the mail again AND stored the attempt number. 40

@arafkarsh arafkarsh Epic – Customer 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 User enters login id and clicks the continue button, the page shows the password page. AND the the user enters password and clicks sign-in button. Then The system validates the credentials and if the credentials are valid then the user is allowed to do the shopping. Else access denied message is shown BDD Acceptance Criteria – 2 : Authentication Given The Request is authenticated When The Input contains login id and password Then The system validates the credentials and if the credentials are valid then the user is allowed to do the shopping. Else access denied message is shown 41

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

@arafkarsh arafkarsh Epic – Product Search 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 product search page is available When The user enters the product name and clicks search Then The system search for the product and if it matches the products in the DB then service returns the result which contains following fields for all the records: Product Name, Product Model, Price, Description, Product Image Else returns zero record. BDD Acceptance Criteria – 2 : Global Search Given Request is authenticated When Input contains Product Name Then The system search for the product and if it matches the products in the DB then service returns the result which contains following fields for all the records: Product Name, Product Model, Price, Description, Product Image Else returns zero record. 43

@arafkarsh arafkarsh Epic – Product Page 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 logged into the portal and a product is searched and results are available When The user then clicks a product for product details Then The system will show that product details based on the product ID with the following details. Product Name, Product Rating, Price, Product Description and Image and buttons to ”Add to Cart” and “Buy Now”. If the product is not available, then the system will show error “Selected Product details are not available”. BDD Acceptance Criteria – 2: Retrieve Product Given The Request is authenticated When The Input contains product id Then The system will return that product details based on the product ID with the following details. Product Name, Product Rating, Price, Product Description and Image If the product is not available, then the system will show error “Selected Product details not available”. Do you want to use HATEOAS with REST? 44

@arafkarsh arafkarsh Epic – Shopping Cart As a Consumer I want to Add a Product to 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 logged into the portal and a Product is selected and Product details are available When The user then clicks Add to Cart Button Then The system will add the Item (Product) into the card and Updates Item counter in the Cart Icon AND Saves the Cart information in the DB AND if the save fails the system shows an Error “Unable to Add Product to the Cart”. BDD Acceptance Criteria – 2: Save Cart Given The Request is authenticated When The Input contains user login id, product id Then The system will add the Item (Product) into the card Saves the Cart information in the DB AND if the save fails the system shows an Error “Unable to Add Product to the Cart”. 45

@arafkarsh arafkarsh Epic – Shopping Cart 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 with the following details Product Item Name, Thumb scale picture, Quantity, Price and Delete Button to delete the item and Sum total of Items and Price. If the Cart is empty (No Records in the DB) then it shows an Empty Cart with a message “Cart is Empty” BDD Acceptance Criteria – 2: Show Cart Given The Request is authenticated When The Input contains user login id Then The system retrieves all the Cart Items from the DB and shows in the UI with the following details Product Item Name, Thumb scale picture, Quantity, Price If the Cart is empty (No Records in the DB) then it shows an Empty Cart with a message “Cart is Empty 46

@arafkarsh arafkarsh Epic – Shopping Cart 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 logged into the portal and clicked the Shopping Cart, and the cart displays all the item When The user then clicks Delete Button for a Product Then The system will delete the Item (Product) from the cart and Updates Item counter in the Cart Icon AND deletes item from the Cart DB AND if the delete fails the system shows an Error “Unable to Delete Product from the Cart”. BDD Acceptance Criteria – 2: Delete item Given The Request is authenticated When The Input contains user login id, 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”. 47

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

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

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

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

@arafkarsh arafkarsh Epic – Customer As a Consumer I want to Reset the Password So that I can login 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 login id and password Then The system validates the email address and the security question AND if they are valid then the system re- generates the password AND Stores the password AND send the new password in an email to the user. AND Stores the status of email delivery. BDD Acceptance Criteria – 2 : Forgot Password Given The login Page contains Forgot Password When The user clicks Forgot Password then the pages shows Forgot Password Page, AND the user enters Email Address and click the continue button AND then the page goes to security page and the user enters the security question and clicks the reset password button Then The system validates the email address and the security question AND if they are valid then the system re- generates the password AND Stores the password AND send the new password in an email to the user. AND Stores the status of email delivery. 52

@arafkarsh arafkarsh Epic – Product Search 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 product search page is available When The user enters the product name AND the Price Range & clicks search Then The system search for the product within the Price Range and if it matches the products in the DB then service returns the result which contains following fields for all the records: Product Name, Product Model, Price, Description, Product Image Else returns zero record. BDD Acceptance Criteria – 2: By Price Range Given The Request is authenticated When The Input contains product name AND the Price Range Then The system search for the product within the Price Range and if it matches the products in the DB then service returns the result which contains following fields for all the records: Product Name, Product Model, Price, Description, Product Image Else returns zero record. 53

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

@arafkarsh arafkarsh Epic – Shopping Cart As a Consumer I want to Update 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 logged into the portal and clicked the Shopping Cart, and the cart displays all the item When The user then input the Quantity for a Product Then The System ensures that the Quantity is greater than ZERO AND the system will update the quantity in the cart DB. AND if there is an error in updating system will show ”Unable to update the Quantity” BDD Acceptance Criteria – 2: Update Quantity Given The Request is authenticated When The Input contains 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” 55

@arafkarsh arafkarsh Epic – Order 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 in the Order Cart Page with Items and selected Shipping Address When User Selects Payment Option As Credit Card and PayPal AND Input the PayPal Details Then The System Validates the PayPal Details IF Invalid Systems says invalid Payment details else Saves the info and proceed for payment. BDD Acceptance Criteria – 3 : Save Payment Given The Request is authenticated When Input contains user login id, order id, payment details (PayPal Details Then The System Validates the PayPal Details IF Invalid Systems returns invalid Payment details ELSE Saves the PayPal Details for Transaction BDD Acceptance Criteria – 3 : Payment Gateway Given The Request is authenticated When Input contains Valid payment details Then With the Valid Payment Details System calls External Payment Service for Payment Processing and Returns Result to Calling System 56

@arafkarsh arafkarsh User Journey / Story Map & Release Cycles Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use PayPal R2 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Minimum Viable Product Scrum Sprint Cycle Search by Price Image Gallery Update Qty Use PayPal Kanban Cycle: Each of the Story can be released without waiting for other stories to be completed resulting in Shorter Releases as all the stories are independent! 57

@arafkarsh arafkarsh Capability Centric Design Summary 1. Business Solutions 1. Business Process 2. Business Capabilities 2. Business Driven Teams (From Specs to Ops) 3. Outcome Oriented instead of Activity Oriented. 4. User Stories 1. Story Points 2. Velocity 5. Behavior Driven Design Business Solution Business Process 1 Business Process 2 Business Process n Business Capability 1 Business Capability 2 Business Capability n User Stories BDD Story Points MVP – User Journey 58

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

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

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

@arafkarsh arafkarsh Scrum Events All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints SPRINT SPRINT PLANNING Max : 8 Hours 1. Why is Sprint Valuable? 2. What can be Done in this Sprint? 3. How will the chosen work get done? Source: https://www.scrum.org/resources/what-is-scrum DAILY SCRUM Max : 15 mins The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. SPRINT REVIEW The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. SPRINT RETROSPECTIVE The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness 62

@arafkarsh arafkarsh Scrum Artifacts PRODUCT BACKLOG The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. SPRINT BACKLOG The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum. INCREMENT An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review 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 63

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

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

@arafkarsh arafkarsh Scrum Values 66

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@arafkarsh arafkarsh Service Based Architecture SOA and Microservices based on Service Based Architecture 1. Distributed Computing: Common thing in Service based architecture is distributed computing. 2. Communication: Services communicate using a Remote Access Protocol (SOAP, REST, RMI, JMS, Message Queues, AMQP (Advanced Message Queuing Protocol) 3. Service Contracts are based on XML, JSON, ProtoBuf etc. Contract versioning is key aspect of the contracts and its future evolution. 4. Availability and Responsiveness: Availability ensures that there are no single point of failures and Responsiveness to ensure that the Service Respond in a timely manner. 5. Security: As Services are independent components, it’s important that security and access controls are taken care off. JSON Web Token is a popular standard. 6. Transactions: Transaction management is a Big challenge in Service based Architecture. 2 Phase Commit or Saga Design Patterns are patterns focusing on addressing these challenges. 81

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

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

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

@arafkarsh arafkarsh DDD: App User’s Journey & Bounded Context An e-Comm App User’s Journey can run across multiple Bounded Context / Microservices. User Journey X Bounded Context Bounded Context Bounded Context User Journey Y Bounded Context Bounded Context Bounded Context Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Understanding Bounded Context (DDD) of a e-Commerce App Product Context Order Context Cart Context Source: Domain-Driven Design Reference by Eric Evans 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? 85

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

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

@arafkarsh arafkarsh Event Sourcing Intro 88 Standard CRUD Operations – Customer Profile – Aggregate Root Profile Address Title Profile Created Profile Address New Title Title Updated Profile New Address New Title New Address added Derived Profile Address Notes Notes Removed Time T1 T2 T4 T3 Event Sourcing and Derived Aggregate Root Commands 1. Create Profile 2. Update Title 3. Add Address 4. Delete Notes 2 Events 1. Profile Created Event 2. Title Updated Event 3. Address Added Event 4. Notes Deleted Event 3 Profile Address New Title Current State of the Customer Profile 4 Event store Single Source of Truth Greg Young

@arafkarsh arafkarsh Event Sourcing & CQRS (Command and Query Responsibility Segregation) • In traditional data management systems, both commands (updates to the data) and queries (requests for data) are executed against the same set of entities in a single data repository. • CQRS is a pattern that segregates the operations that read data (Queries) from the operations that update data (Commands) by using separate interfaces. • CQRS should only be used on specific portions of a system in Bounded Context (in DDD). • CQRS should be used along with Event Sourcing. 89 MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx | Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html CQS : Bertrand Meyer Axon Framework For Java Java Axon Framework Resource : http://www.axonframework.org Greg Young

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

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

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

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

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

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

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

@arafkarsh arafkarsh DDD: App User’s Journey & Bounded Context An e-Comm App User’s Journey can run across multiple Bounded Context / Microservices. User Journey X Bounded Context Bounded Context Bounded Context User Journey Y Bounded Context Bounded Context Bounded Context Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Understanding Bounded Context (DDD) of a e-Commerce App Product Context Order Context Cart Context Source: Domain-Driven Design Reference by Eric Evans 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? 97

@arafkarsh arafkarsh DDD: Bounded Context – Strategic Design An App User’s Journey can run across multiple Bounded Context / Micro Services. Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Understanding Bounded Context (DDD) of a Restaurant App Dinning Context Kitchen Context Menu Context 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 98

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

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

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

@arafkarsh arafkarsh Customer Model in Different Bounded Context Order Customer • Customer ID • Discount • Bonus Program Delivery Customer • Customer ID • Address • Preferred Delivery method • Packaging • Delivery Contact Billing Customer • Customer ID • Billing Address • Payment Type • Tax o Customer Model has different attributes in different contexts. So it avoids storing all the customer info in one place and then sharing that across multiple Bounded Contexts (Microservices). o If you want to change Customer details related to Tax then only Billing Bounded Context (Microservice) needs to be updated. 102

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

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

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

@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, adapters for external entities are on the outside of the port. The notion of a “port” invokes the OS idea that any device that adheres to a known protocol can be plugged into a port. Similarly many adapters may use the Ports. Source : http://alistair.cockburn.us/Hexagonal+architecture https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net Services for UI Ports File system Database Order Tracking JPA Repository Implementation Adapters OrderProcessing Domain Service (Business Rules) Implementation Domain Models Domain Layer Order Data Validation OrderService REST Service Implementation OrderProcessing Interface p Order Tracking Repository Interface p A A External Apps A A A Others A A OrderService Interface p Web Services Data Store Use Case Boundary Bounded Context A • Reduces Technical Debt • Dependency Injection • Auto Wiring 106

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

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

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

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

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

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

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

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

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

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

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

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

@arafkarsh arafkarsh Summary: User Journey / CCD / Domain Driven Design User Journey Bounded Context 1 Bounded Context 2 Bounded Context 3 1. Bounded Contexts 2. Entity 3. Value Objects 4. Aggregate Roots 5. Domain Events 6. Repository 7. Service 8. Factory Front-End Back-End Database Business Capability 1 Front-End Back-End Database Business Capability 2 Front-End Back-End Database Business Capability 3 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 119

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

@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. Up Stream (u) – Down Stream (d) The upstream team may succeed independently of the fate of the downstream team. Mutually Dependent Success depends on the success of both the teams. Free In which success or failure of the development work in other contexts has little affect on delivery. 121

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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. The Problem Assembler Pattern An object that carries data between processes in order to reduce the number of method calls. Benefits 1. Reduced Number of Calls 2. Improved Performance 3. Hidden Internals 4. Discovery of Business objects Liabilities 1. Class Explosion 2. Additional Computation 3. Additional Coding Effort https://msdn.microsoft.com/en-us/library/ms978717.aspx Problem: How do you preserve the simple semantics of a procedure call interface without being subject to the latency issues inherent in remote communication? The Solution 401 P of EAA 142

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

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

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

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

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

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

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

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

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

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

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

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

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

@arafkarsh arafkarsh Summary: User Journey / CCD / Domain Driven Design User Journey Bounded Context 1 Bounded Context 2 Bounded Context 3 1. Bounded Contexts 2. Entity 3. Value Objects 4. Aggregate Roots 5. Domain Events 6. Repository 7. Service 8. Factory Front-End Back-End Database Business Capability 1 Front-End Back-End Database Business Capability 2 Front-End Back-End Database Business Capability 3 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 156

@arafkarsh arafkarsh RESTful APIs • Standards • Api versioning standards 157 4

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

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

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

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

@arafkarsh arafkarsh Open API 3.0 162

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

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

@arafkarsh arafkarsh Open API 3.0 Documentation Example GET / 167

@arafkarsh arafkarsh Open API 3.0 Documentation Example POST / 168

@arafkarsh arafkarsh Open API 3.0 Documentation Example PUT / 169

@arafkarsh arafkarsh Open API 3.0 Documentation Example DELETE / 170

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

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

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

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

@arafkarsh arafkarsh 175 DREAM | AUTOMATE | EMPOWER Araf Karsh Hamid : India: +91.999.545.8627 http://www.slideshare.net/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.arafkarsh.com/ @arafkarsh arafkarsh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@arafkarsh arafkarsh References 192 16. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 17. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 18. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ 19. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs 20. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 21. CQS : http://en.wikipedia.org/wiki/Command–query_separation 22. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 23. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 24. CAP 12 years how the rules have changed 25. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 26. Pat Helland (Amazon) : Life beyond distributed transactions 27. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 28. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem 29. Rx Observable : https://dzone.com/articles/using-rx-java-observable

Agile, User Stories, Domain Driven Design

More Related Content

What's hot

Similar to Agile, User Stories, Domain Driven Design

More from Araf Karsh Hamid

Recently uploaded

Agile, User Stories, Domain Driven Design

Editor's Notes