Building Cloud-Native App Series - Part 1 of 15
Microservices Architecture Series
Design Thinking,
Lean Startup,
Agile (Kanban, Scrum),
Epics, User Stories,
BDD - Acceptance Criteria
Domain-Driven Design
@arafkarsh arafkarsh 8 Years Network & Security 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Distributed Computing Architecting & Building Apps a tech presentorial Combination of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh 1 Microservice Architecture Series Design Thinking / Lean Startup Agile (Scrum/Kanban) / User Stories Architecture Styles Domain Driven Design RESTful / Open API 3.0 Part 1 of 15 To Build Cloud Native Apps Using Composable Enterprise Architecture
@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 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 6 Design Thinking Lean Agile Explore the Problem Build the right things Build the things right 0
@arafkarsh arafkarsh Product Mindset 7 Identify the Problem Define the Value Validate the Outcome Discovery is the new knowing Until proven by market response, outcomes are merely conjectures. The worth of a product is determined by the amount a customer is willing to spend on it. Source: https://www.clearlyagile.com/agile-blog/3-steps-to-grow-our-product-mindset Examples 1. Google Gmail (Search, UI, Storage) 2. Apple iPod ($0.99 Song, UI, Storage)
@arafkarsh arafkarsh Discovery Vs. Delivery 8 Increasing level of Evidence of Value Increasing level of Effort Developing a product without finding evidence of its value is a waste of time and resources. Observe & Interact Protypes Explainer Videos Landing Pages Concierge MVP Wizard of OZ MVP Beta Release Product Launch Design Thinking Lean Agile Explore the Problem Build the right things Build the things right If You are NOT doing these Then this is waste Single Customer Example Amazon had Human Book Reviewers before they automated it Example Dropbox: Customer interests went up from 5K to 70K
@arafkarsh arafkarsh Design Thinking 9 Empathize 1 Define 2 Ideate 3 Prototype 4 • Who the user is (User Profile / Persona)? • What their needs are? What do they do? Test 5 Is a Philosophy and a set of tools to solve the problem Creatively. Human Centered Design Don’t worry about Technology • From Step 1: Observations, Discoveries, Challenges >> Insights • Defines the Problem • Ideas, Solutions • Potential Matches • Select and Turn the Ideas into • Testable Prototypes • Test with Real users • Gather the Feedback, Observations, New Insights
@arafkarsh arafkarsh Design Thinking Business Thinking Design Thinking Market Analysis What might be Definitive Iterative Focus Groups Observation Spreadsheets Stories / Scenarios Individual Responsibility Collaboration Permanent Jobs Temporary Projects 10 Tom Klinkowstein – Professor of Design & New Media, New York
@arafkarsh arafkarsh 11 Lean Startup Build Measure Learn Design Thinking 1 Feedback Loop 2 Experiment Observe Don’t Ask 1 2 3 • Movie Streaming (NetFlix), Music Streaming (Spotify), • Drive In Takeaways (McDonalds), Build your furniture (IKEA) 3 Minimum Viable Product (MVP) Eric Ries Video MVP Concierge MVP Wizard of OZ • DropBox Video Demo • Steve Jobs Next OS • Single Customer • Adapt the features to other customers later • Amazon had Human Book Reviewers before they automated it.
@arafkarsh arafkarsh Agile Manifesto (Values) 13 INDIVIDUALS AND INTERACTIONS OVER PROCESSESS AND TOOLS WORKING SOFTWARE COMPREHENSIVE DOCUMENTATION OVER CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION RESPONDING TO CHANGE OVER FOLLOWING A PLAN Source: Agile Manifesto - https://www.scrumalliance.org/resources/agile-manifesto
@arafkarsh arafkarsh Three Mindsets of Product Development 14 Design Thinking Lean Agile Source: Jonny Schneider, Thought Works Explore the Problem Build the right things Build the things right Hypothesis Validation New Business Requirements Product Evolutions Agile MVP
@arafkarsh arafkarsh 3 Mindset of Product Development 15 Increasing level of Evidence of Value Increasing level of Effort Developing a product without finding evidence of its value is a waste of time and resources. Observe & Interact Protypes Explainer Videos Landing Pages Concierge MVP Wizard of OZ MVP Beta Release Product Launch Design Thinking Lean Agile Explore the Problem Build the right things Build the things right If You are NOT doing these Then this is waste Single Customer Example Amazon had Human Book Reviewers before they automated it Example Dropbox: Customer interests went up from 5K to 70K The Problem The Solution
@arafkarsh arafkarsh Design Thinking / Lean / Agile 17 Principles Foundation 1 Customer Value / Business Value User Centered Approach 2 Work in Short Cycles Evidence based Decision Making 3 Hold Regular Retrospectives Improve the Product 4 Go and See Amplify Good Patterns 5 Test High Risk Hypothesis Focus on High value 6 Do Less More often Understand the Pain points 7 Work as a Balanced Team Small Team works one thing at a time 8 Radical Transparency Transparency through Rituals 9 Incentives Ship software to Deliver Customer Value 10 Learning a 1st Class Citizen of backlog Continuous Learning Source: Jeff Gothelf : Lean vs Agile vs Design Thinking : https://www.youtube.com/watch?v=_4VPfmtwRac Integrate the Principles Not Process
@arafkarsh arafkarsh From Object Modeling to Process Modeling 19 Developers with Strong Object Modelling will experience a big Mind Shift to transition to Process based modelling with Events. The Key is: 1. App User’s Journey 2. Business Process 3. Ubiquitous Language – DDD 4. Capability Centric Design 5. Outcome Oriented The Best tool to define your process and its tasks. How do you define your End User’s Journey & Business Process? • Think It • Build It • Run IT
@arafkarsh arafkarsh Business Solution & Business Process 20 q Business Solution focuses on the entire Journey of the User, which can run across multiple Microservices. q Business Solution comprises a set of Business Processes. q A specific Microservice functionality will be focused on a Business Process / Concern. q Business Processes can be divided further into Business Functions
@arafkarsh arafkarsh Levels of Data Flow Diagram 21 0-level DFD / System Context Design: It represents the entire system as a single bubble and provides an overall picture of the system. 1-level DFD: It represents the main Processes of the system and how they interact with each other. 2-level DFD: It represents the sub-processes within each Main Process of the system and how they interact with each other. 0 1 2 Business Solution Business Process Business Function
@arafkarsh arafkarsh Business Solution & Business Process 22 Business Solution: Customer Dining Experience Order Payment Food Menu Kitchen Dining Browse Menu Order Dinner Dinner Served Get Bill Make Payment User Journey with Story Map Business Solution: User Shopping Experience Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search
@arafkarsh arafkarsh Business Capability Centric Design 23 Business Centric Development • Focus on Business Capabilities • Entire team is aligned towards Business Capability. • From Specs to Operations – The team handles the entire spectrum of Software development. • Every vertical will have its own Code Pipeline, Build Pipeline Front-End-Team Back-End-Team Database-Team In a typical Monolithic way, the team is divided based on technology/skill set rather than business functions, leading to bottlenecks and a lack of understanding of the Business Domain. QA Team QA = Quality Assurance PO = Product Owner Vertically sliced Product Team Front-End Back-End Database Business Capability 1 QA PO Ops Front-End Back-End Database Business Capability 2 QA PO Ops Front-End Back-End Database Business Capability - n QA PO Ops
@arafkarsh arafkarsh From Project Based Activity Oriented To Product Based Outcome Oriented Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html 24 Traditional corporate IT organizations operate in an activity-oriented manner where they fund projects with set time-spans. Organizations that are outcome-oriented align better with business outcomes, but project-based funding undermines long- term effectiveness. Basing funding on products centered around long-term business capabilities creates stable teams that are aligned with business needs. Outcome-oriented thinking compels business capability centered organizations to consider more than just delivering the scope, which is where we want to be. Project based Product based Activity Oriented Outcome Oriented Business Capability Centric
@arafkarsh arafkarsh User Stories • User Stories • Behavior Driven Design • Writing Good Stories • Estimate and Planning • Case Study 25 Theme / Initiatives Epic User Story Sprint
@arafkarsh arafkarsh User Story 26 Role-Feature-Reason Matrix Story Card These three elements (WHO, WHAT, WHY) are the building blocks of User stories. Element Example Role WHO: As an e-Commerce Retailer Feature WHAT: I want to know who my Gold Customers are Reason WHY: So that I sell more Element Definition WHO: Establishes the user or users or another service. WHAT: Describes the Activity – Key Axis of the Story. What the user does in the story. WHY: This describes the purpose of the story. Source: User Story A Pragmatic View, Page 9. Published 0ct 19, 2019 User stories are NOT 1. IEEE 830 Software Specs 2. Use Cases Use Cases are a combination of User Story and Acceptance Criteria 3. Scenarios
@arafkarsh arafkarsh Acceptance Criteria / Behavior Driven Development 27 Source: https://dannorth.net/introducing-bdd/ Given Customer John Doe exists When he buys products ABC for $1000 USD Then He becomes a Gold Customer BDD Construct Acceptance Criteria The definition of Done – As per Scrum These three elements (GIVEN WHEN THEN) are the building blocks of Acceptance Criteria. Typical SDLC Life Cycle Analyst Specifies the Use Case Developer The developer builds software based on Specific Usage scenarios with respect to the Use Case. Tester Tester builds test cases based on Use Case Scenarios and finds issues. The Gaps identified in this process are filled up by linking the User Stories with Acceptance Criteria.
@arafkarsh arafkarsh INVEST in Good Stories 28 Source: INVEST in Good Stories, and SMART Tasks https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ Term Description I Independent No overlapping but independent Stories. 3 Forms of Dependencies 1. Overlap 2. Order 3. Containment. N Negotiable A good story is not an explicit contract for features. A good story captures the essence and not the details. Over a period, a Story may attract special notes, test ideas and others. However, this is not required to prioritize and schedule the story. V Valuable Story must be valuable to the customer. E.g., (IRACIS) Increase Revenue, Avoid Cost, Improve Service. E Estimable An estimate (not necessarily precise) but to focus on priority and implementation. You can use Function Points, COCOMO etc. S Small Any story that goes beyond few weeks is big and may be ambiguous. It’s important to keep the Story small. T Testable A good story is testable. Testable story clearly establishes the spec from Customer perspective.
@arafkarsh arafkarsh 3 C’s of User Stories 29 Card Conversation Confirmation A Story card provides the written description of the Story. It helps in planning and estimation. The conversation is the discussion between Product Owners, Users, and the Engineering team to bring clarity to the stories. These are the Acceptance Criteria that need to be satisfied to ensure that the Story meets all the requirements.
@arafkarsh arafkarsh User Stories – Small Stories 30 • User Story should take a maximum of 3-5 person days to complete the story. (From Analysis + Design + Deploy + Test + Fix + Re-Deploy) • User Stories can be smaller from a few hours to 1-2 Person days. • Each story can have 3-7 Acceptance criteria. • Sprint backlog will be having 6-10 stories. • If a story survives more than 1 sprint, then the story needs to break down into smaller stories. Source: User Story A Pragmatic View, Page 78-80. Published 0ct 19, 2019
@arafkarsh arafkarsh Features of BDD 31 • Focus on Behavior of the System rather than tests. • Collaboration between Business Stake holders, Analysts, Developers, QA. • Ubiquitous Language • Driven By Business Value • Extends Test Driven Development Source: https://cucumber.io/ Cucumber merges specification and test documentation into one cohesive whole.
@arafkarsh arafkarsh User Story / Behavior Driven Development 32 Source: https://dannorth.net/introducing-bdd/ As an an e-Commerce Retailer I want to know who my Gold Customers are So that I sell more Given Customer John Doe exists When he buys products ABC for $1000 USD Then He becomes a Gold Customer Role-Feature-Reason Matrix As a Customer I want to withdraw Cash from ATM So that I don’t have to wait in line at the bank Given The account is in Credit AND the Card is Valid AND the dispenser contains Cash Role-Feature-Reason Matrix When The Customer requests Cash Then Ensure that the Account is debited AND Ensure cash is dispensed AND ensure that Card is returned. BDD Construct Acceptance Criteria BDD Construct Acceptance Criteria User Story – 1 User Story – 2
@arafkarsh arafkarsh Estimate – Story Points / Velocity 33 Story Point – An Ideal day’s work (8 Hour). Means – no meetings, no emails, no phone calls etc. 1. Clarifying with Customer 2. Time to Develop 3. Write Test Cases 4. Testing 5. Deploy 6. Verify The key over here is Reasonable rather than being Precise. Source: User Stories Applied by Mike Cohn Velocity Velocity is the number of story points the team completes in an iteration.
@arafkarsh arafkarsh Planning – MoSCoW Rules 34 Code Priority Description Mo Must Have These features are fundamental to the Application S Should Have These are important however; work arounds are available. Co Could Have Can be left out if the developer runs out of time. W Won’t Have Feature can be planned in a future release. Release Plans • All the story points prioritized as per the customer • Story Points are mapped to a set of iterations. • Estimated Velocity for each Iteration • For Ex. If there are 200 Story Points • 20 Story Points are allocated at each Iteration • Then 10 iteration is required
@arafkarsh arafkarsh Story Anti-Patterns 35 Anti Pattern Details 1 Too Small Story 1. Export Report in Excel Format Story 2. Export Report in PDF Format. These can be combined to a Single story. 2 Interdependent Stories This can cause planning issue. Remove the dependency or combine into a Single Story. 3 Gold Plating Addition of un-necessary features by the developers. 4 Too Many Details Too much time is spent in gathering details. 5 Early UI Definition Including UI details too soon 6 Look Ahead Upfront Large Requirements gathering. 7 Splitting Too many stories 1. The Story is too large to fit into the iteration 2. Story contains High Priority and Low Priority items. 8 Unable to Prioritize Prioritization will be difficult if the business value can’t be determined Source: User Stories Applied by Mike Cohn. Page 191
@arafkarsh arafkarsh Why User Stories • User stories emphasize verbal communication. • User stories are comprehensible by everyone. • User stories are the right size for planning. • User stories work for iterative development. • User stories encourage deferring detail. • User stories support opportunistic design. • User stories encourage participatory design. • User stories build up tacit knowledge. 36 Source: User Stories Applied by Mike Cohn. Page 178
@arafkarsh arafkarsh User Stories – Case Study • Minimum Viable Product • Case Study – eCommerce Application – ShopEasy • User Journey and Story Map 37
@arafkarsh arafkarsh Example 3: Space Shuttle Launch 41 Theme / Initiative Epic User Story Sprint Shuttle Launch / Pre-Launch Preparation 1. Develop & Test Shuttle Systems 2. Astronaut Training 2. Training Release 1 1. Mission Training Release 2 1. Emergency Training Stories 1. Mission Training 2. Emergency Training Shuttle Launch / Launch Execution 1. Coordinate Launch Logistics 2. Monitor and Control Launch Operations Stories 1. Launch Sequence 2. Comm with Astronauts 2. Monitor & Control Release 1 1. Launch Sequence 2. Comm with Astronauts
@arafkarsh arafkarsh User Journey with Story Map & Release Cycles 43 1. Register 3. Make Appointment 4. Diagnosis and Prescription 6. Get Medicine 5. Lab Tests Health Staff Appointment Pharmacy Lab Diagnosis 2. Search & Select Doctor Patient User Journey Minimum Viable Product Upload Medical Docs Add Doctor / Nurse Cancel Appointment R2 Lab Tests View Medical History Duty Calendar R3 Reschedule Register Search Doctor Available Dates Book Appointment Medical History Check Verify Prescription Pack Medicines R1 Pre-Checkup Diagnosis & Prescription Appointment Upload Results Schedule Duty Time Make Payment Share Medical Docs R4 Appointment Calendar Make Payment View Appointments Email SMS
@arafkarsh arafkarsh Example 5: eCommerce Portal / Shop Easy 44 Theme / Initiative Epic User Story Sprint eCommerce / Shop Easy 1. Customer Management 2. Search Product 3. Catalogue 4. Shopping Cart 5. Order Processing 6. Payments 2. Search Product Release 1 1. Global Search Release 2 1. Search by Brand 2. Search by Price Range Release 3 1. Search by Model 2. Search by Rating Stories 1. Global Search 2. Search by Brand 3. Search by Price Range 4. Search by Model 5. Search by Rating
@arafkarsh arafkarsh User Journey with Story Map 45 Global Search Search by Brand Search by Price Search by Model Search by Rating Product Details Image Gallery Product Reviews User Shopping Experience Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Add to Cart Update Qty Delete Item Make Payment Confirm Order Pay Credit Card Pay Debit Card Use PayPal Select Address Registration
@arafkarsh arafkarsh User Journey with Story Map & Release Cycles 46 Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use PayPal R2 Search by Brand Product Reviews Pay Debit Card R3 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Search by Model Search by Rating R4 Minimum Viable Product
@arafkarsh arafkarsh 48 Shopping Portal /Web App /Authentication /product /review API Gateway Nodes Firewall Web App Pod Web App Pod Web App Service N2 N1 Product Pod Product Pod Product Pod Product Service N4 N3 MySQL DB Review Pod Review Pod Review Pod Review Service N4 N3 N1 Users Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP) Mongo DB Mongo DB Auth Pod Auth Pod Auth / Authorize Service N3 N5 MySQL DB Generates Token (JWT) Services will process requests only if the token is valid
@arafkarsh arafkarsh 49 Shopping Portal /Customer /Shopping Cart /Order Load Balancer API Gateway Nodes Firewall Order Pod Order Pod Order Pod Order Service N4 N3 MySQL DB Users Payment Pod Payment Pod Payment Service N4 N3 Cart Pod Cart Pod Cart Pod Cart Service N1 N2 N2 Redis DB Services will process requests only if the token is valid External Payment Service Routing based on Layer 3 (IP), 4 (TCP) and 7 ((HTTP) Customer Pod Customer Pod Customer Service N1 N2 Redis DB
@arafkarsh arafkarsh Epic – Customer 51 As a Consumer I want to register eCommerce Portal So that I can buy products Role-Feature-Reason Matrix User Story – 1 : Registration BDD Acceptance Criteria – 1: Save User Given The fields First Name, Last Name, DOB Address, Email Address, Phone No. When The user enters values in the fields First Name, Last Name, DOB Address, Email Address, and Phone No. Then If the following fields contain values First Name, Last Name, Address, Email Address, and Phone No. AND Age is greater than 18, then Save the Data. BDD Acceptance Criteria – 2 : Generate Password Given User Info Available When The email address is a valid email id. Then Generate the Password AND Send mail with the user email address as login id and the URL of the portal AND Send the Password to a separate email address. AND Store data on mail status as mail sent or failed. BDD Acceptance Criteria – 3 : Resend Mail Given User Registration mail status is available. When The Mail status is equal to "Failed". Then Send the mail again AND store the attempt number.
@arafkarsh arafkarsh Epic – Auth 52 As a Consumer I want to login to eCommerce Portal So that I can buy products Role-Feature-Reason Matrix User Story – 2 : Portal Login BDD Acceptance Criteria – 1 : Authentication Given The user clicks the login page, and the portal goes to the login page with the fields login id and continue button. When The user enters the login id and clicks the continue button, and the page shows the password page. AND the user enters the Password and clicks the sign-in button. Then The system validates the credentials, and IF the credentials are valid, then the user is allowed to do the shopping. Else access denied message is shown. BDD Acceptance Criteria – 2 : Authentication Given The Request is authenticated. When The Input contains the login id and Password. Then The system validates the credentials, and IF the credentials are valid, then the user is allowed to do the shopping. Else access denied message is shown.
@arafkarsh arafkarsh Epic – Search (Product) 54 As a Consumer I want to search for a product So that I can buy products Role-Feature-Reason Matrix User Story – 1 : Global Search BDD Acceptance Criteria – 1 : Global Search Given The user logged into the portal, and the product search page was available. When The user enters the product name and clicks search Then The system search for the Product, and IF it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, Product Image ELSE returns zero records. BDD Acceptance Criteria – 2 : Global Search Given The Request is authenticated. When Input contains Product Name Then The system search for the Product, and IF it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, Product Image ELSE returns zero records.
@arafkarsh arafkarsh Epic – Product Page 55 As a Consumer I want to check a Product So that I can buy the Product Role-Feature-Reason Matrix User Story – 1 : Show Product BDD Acceptance Criteria – 1: Show Product Given The user logs into the portal, a Product is searched, and results are available. When The user then clicks a product for product details Then The system will show product details based on the product ID with following details. Product Name, Product Rating, Price, Product Description and Image, and buttons to " Add to Cart" and "Buy Now." IF the Product is not available, then the system will show the error "Selected Product details are not available." BDD Acceptance Criteria – 2: Retrieve Product Given The Request is authenticated When The Input contains Product id Then The system will return the product details based on the product ID with the following details. Product Name, Product Rating, Price, Product Description, and Image IF the Product is not available, then the system will show the error "Selected Product details not available."
@arafkarsh arafkarsh Epic – Shopping Cart 56 As a Consumer I want to Add a Product to the Cart So that I can buy the Product Role-Feature-Reason Matrix User Story – 1 : Add to Cart BDD Acceptance Criteria – 1: Add to Cart Given The user logs into the portal, a Product is selected, and Product details are available. When The user then clicks Add to Cart Button. Then The system will add the Item (Product) to the Cart and Update the Item counter in the Cart Icon AND Saves the Cart information in the DB, AND if the save fails, the system shows an Error "Unable to Add Product to the Cart." BDD Acceptance Criteria – 2: Save Cart Given The Request is authenticated. When The Input contains the user login id and Product id. Then The system will add the Item (Product) to the Cart Saves the Cart information in the DB AND if the save fails, the system shows an Error "Unable to Add Product to the Cart."
@arafkarsh arafkarsh Epic – Shopping Cart 57 As a Consumer I want to see all the items in the Cart So that I can buy the Product Role-Feature-Reason Matrix User Story – 2 : Show Cart BDD Acceptance Criteria – 1: Show Cart Given The user logged into the portal. When The user then clicks Cart. Then The system retrieves all the Cart Items from the DB and shows in the UI the following details Product Item Name, Thumb scale picture, Quantity, Price, and Delete Button to delete the item and Sum total of Items and Price. IF the Cart is empty (No Records in the DB), then it shows an Empty Cart with the message "Cart is Empty." BDD Acceptance Criteria – 2: Show Cart Given The Request is authenticated. When The Input contains the user login id. Then The system retrieves all the Cart Items from the DB and shows in the UI the following details. Product Item Name, Thumb scale picture, Quantity, Price IF the Cart is empty (No Records in the DB), then it shows an Empty Cart with the message “Cart is Empty."
@arafkarsh arafkarsh Epic – Shopping Cart 58 As a Consumer I want to Delete a Product from the Cart So that I can buy other items in the Cart. Role-Feature-Reason Matrix User Story – 3 : Delete from Cart BDD Acceptance Criteria – 1: Delete From Cart Given The user logs into the portal and clicks the Shopping Cart, and the cart displays all the items. When The user then clicks Delete Button for a Product. Then The system will delete the Item (Product) from the Cart and update the Item counter in the Cart Icon. AND deletes an item from the Cart DB AND if the delete fails, the system shows an Error" Unable to Delete Product from the Cart." BDD Acceptance Criteria – 2: Delete item Given The Request is authenticated. When The Input contains the user login id and Product id. Then The system will delete the Item (Product) from the cart DB AND if the delete fails, the system shows an Error "Unable to Delete Product from the Cart."
@arafkarsh arafkarsh Epic – Customer 59 As a Consumer I want to Select Shipping Address So that I can ship the items to that Address Role-Feature-Reason Matrix User Story – 3 : Select Address BDD Acceptance Criteria – 1 : Show Address Given The user is on the Shopping Cart Page. When The user Clicks Proceed to Buy Button. Then The System shows the Available Addresses for Shipping. BDD Acceptance Criteria – 2 : Select Address Given The user in the Shopping Cart Page with Available Shipping Address When The user Selects the Address and Clicks Proceed to Buy. Then The System saves the Temp Order details from Items from Shopping and Selected Shipping Address AND these details are valid only for the user session. If the order is not placed, Temp Order items will be put back in Cart DB. BDD Acceptance Criteria – 3 : Save Temp Order Given The Request is authenticated. When The input contains the user login id, items, and shipping address. Then The System saves the Temp Order details from Items from Shopping and Selected Shipping Address AND these details are valid only for the user session. If the order is not placed, Temp Order items will be put back in Cart DB.
@arafkarsh arafkarsh Epic – Order : Credit Card 60 As a Consumer I want to Process the Order So that I can buy Products Role-Feature-Reason Matrix User Story – 1 : Process Order BDD Acceptance Criteria – 1 : Add Payment Given The user is on the Order Page with Items and selected Shipping Address. When The user Selects the Payment Option As a Credit Card AND Input the Credit Card Details in the following fields Card Name, Card No. Expiry Date (MM/YYYY), CVV Number. Then The System Validates the Credit Card Number and the Expiry Date, Card Name & CVV. These data Must NOT be Null IF Invalid, THEN Systems say invalid Payment details, ELSE Saves the info and proceeds with the payment. BDD Acceptance Criteria – 3 : Save Payment Given The Request is authenticated. When The input contains the user login id, order id, and payment details (card number only last four digits). Then The System Validates the Credit Card Number and the Expiry Date, Card Name & CVV. These data Must NOT be Null IF Invalid, THEN Systems say invalid Payment details, ELSE Saves the following info Card Name, Card Number (only last 4 digits), Expiry Date and proceeds with the payment. BDD Acceptance Criteria – 3 : Payment Gateway Given The Request is authenticated. When The input contains Valid payment details. Then The Request with the valid Payment Details, the System calls the External Payment Service for Payment Processing and Returns the Result to the Calling System.
@arafkarsh arafkarsh Epic – Payment 61 As a Consumer I want to Make a Payment So that I can buy Products Role-Feature-Reason Matrix User Story – 1 : Make Payment BDD Acceptance Criteria – 1 : Process OTP Given The user Enters the Payment Details and Clicked Proceed to Buy, and the System shows the Payment Service Page. When The user Enters One Time Password (OTP) and clicks Proceed. Then The System Sends the OTP to the External Payment Gateway, and the result is returned to the Caller. BDD Acceptance Criteria – 2 : Order Status Given The Request is authenticated. When The input contains Payment Status. Then IF the Payment is successful, the Order Status is changed to Successful ELSE, the items are returned to the Cart.
@arafkarsh arafkarsh Epic – Auth 63 As a Consumer I want to Reset the Password So that I can log in to Portal. Role-Feature-Reason Matrix User Story – 3 : Forgot Password BDD Acceptance Criteria – 1 : Forgot Password Given The Request is authenticated. When The Input contains the login id and password. Then The System validates the email address and the security question AND if they are valid, then the system re- generates the password AND Stores the password (Hashed) AND send the new password in an email to the user. AND Stores the status of email delivery. BDD Acceptance Criteria – 2 : Forgot Password Given The login page contains Forgot Password link. When The user clicks Forgot Password link then the page shows Forgot Password Page, AND the user enters their Email Address and clicks the continue button AND then, the page goes to the security page, and the user enters the security question and clicks the reset password button. Then The System validates the email address and the security question AND if they are valid, then the system re- generates the password AND Stores the password (Hashed) AND send the new password in an email to the user. AND Stores the status of email delivery.
@arafkarsh arafkarsh Epic – Search (Product: Price Range) 64 As a Consumer I want to search for a Product within a price range So that I can buy Products. Role-Feature-Reason Matrix User Story – 2 : Search By Price Range BDD Acceptance Criteria – 1: By Price Range Given The user logged into the Portal, and the product search page was available. When The user enters the Product name AND the Price Range & clicks search. Then The System search for the Product within the Price Range, and if it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, and Product Image. Else returns zero records. BDD Acceptance Criteria – 2: By Price Range Given The Request is authenticated. When The Input contains the Product name AND the Price Range. Then The System search for the Product within the Price Range, and if it matches the products in the DB, then the service returns the result, which contains the following fields for all the records: Product Name, Product Model, Price, Description, and Product Image. Else returns zero records.
@arafkarsh arafkarsh Epic – Product Page 65 As a Consumer I want to check a Product So that I can buy the Product. Role-Feature-Reason Matrix User Story – 2 : Show Product with Image Gallery BDD Acceptance Criteria – 1: Show Product Given The user logs into the Portal, a Product is searched, and results are available. When The user then clicks a product for product details. Then The System will show product details based on the product ID with the following information. Product Name, Product Rating, Price, Product Description and Image Gallery, and buttons to "Add to Cart" and "Buy Now." If the Product is not available, then the System will show an error "Selected Product details are not available." BDD Acceptance Criteria – 2: Retrieve Product Given The Request is authenticated. When The Input contains the product id. Then The System will return the product details based on the product ID with the following information. Product Name, Product Rating, Price, Product Description, and Image Gallery If the Product is not available, then the System will show an error "Selected Product details not available."
@arafkarsh arafkarsh Epic – Shopping Cart 66 As a Consumer I want to Update the Quantity of a Product in the Cart So that I can buy the Product. Role-Feature-Reason Matrix User Story – 3 : Update the Cart BDD Acceptance Criteria – 1: Update Quantity Given The user logs into the Portal and clicks the Shopping Cart, and the Cart displays all the items. When The user then inputs the Quantity for a Product. Then The System ensures that the Quantity is greater than ZERO AND the System will update the Quantity in the cart DB. AND if there is an error in updating System will show "Unable to update the Quantity." BDD Acceptance Criteria – 2: Update Quantity Given The Request is authenticated. When The Input contains the user login id, product id, and Quantity. Then The System ensures that the Quantity is greater than ZERO AND the System will update the Quantity in the cart DB. AND if there is an error in updating System will show "Unable to update the Quantity."
@arafkarsh arafkarsh Epic – Order : PayPal 67 As a Consumer I want to Process the Order So that I can buy Products Role-Feature-Reason Matrix User Story – 1 : Process Order BDD Acceptance Criteria – 1 : Add Payment Given The user is on the Order Cart Page with Items and selected Shipping Address. When The user Selects Payment Option As PayPal AND Input the PayPal Details. Then The System Validates the PayPal Details IF Invalid, Then the System returns "Invalid Payment details." ELSE Saves the info and proceeds with Payment. BDD Acceptance Criteria – 3 : Save Payment Given The Request is authenticated. When The input contains the user login id, order id, and payment details (PayPal Details). Then The System Validates the PayPal Details IF Invalid, Then the System returns "Invalid Payment details." ELSE Saves the info and proceeds with Payment. BDD Acceptance Criteria – 3 : Payment Gateway Given The Request is authenticated. When The input contains Valid payment details. Then The Request with the Valid Payment Details, the System calls the External Payment Service for Payment Processing and Returns the Result to the Calling System.
@arafkarsh arafkarsh 68 User Journey / Story Map & Release Cycles Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use PayPal R2 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Minimum Viable Product Scrum Sprint Cycle Search by Price Image Gallery Update Qty Use PayPal Kanban Cycle: Each of the Stories can be released without waiting for other stories to be completed resulting in Shorter Releases as all the stories are independent!
@arafkarsh arafkarsh Capability Centric Design Summary 69 1. Business Solutions 1. Business Process 2. Business Capabilities 2. Business Driven Teams (From Specs to Ops) 3. Outcome Oriented instead of Activity Oriented. 4. User Stories 1. Story Points 2. Velocity 5. Behavior Driven Design Business Solution Business Process 1 Business Process 2 Business Process n Business Capability 1 Business Capability 2 Business Capability n User Stories BDD Story Points MVP – User Journey
@arafkarsh arafkarsh Agile Values 71 INDIVIDUALS AND INTERACTIONS OVER PROCESSESS AND TOOLS WORKING SOFTWARE COMPREHENSIVE DOCUMENTATION OVER CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION RESPONDING TO CHANGE OVER FOLLOWING A PLAN Source: Agile Manifesto - https://www.scrumalliance.org/resources/agile-manifesto
@arafkarsh arafkarsh Scrum Events 73 Sprints encompass all the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives. SPRINT SPRINT PLANNING Max : 8 Hours 1. Why is Sprint Valuable? 2. What can be Done in this Sprint? 3. How will the chosen work get done? Source: https://www.scrum.org/resources/what-is-scrum DAILY SCRUM Max : 15 mins The Daily Scrum seeks to examine the progress made toward the Sprint Goal and adjust the Sprint Backlog as needed, modifying the planned work for the upcoming period. SPRINT REVIEW During the Sprint Review, the Scrum Team inspects the Sprint's outcome and determines any necessary adaptations for the future. They present their work results to critical stakeholders, and the group discusses progress toward the Product Goal. SPRINT RETROSPECTIVE The Sprint Retrospective aims to plan ways to increase quality and effectiveness.
@arafkarsh arafkarsh Scrum Artifacts 74 PRODUCT BACKLOG The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. SPRINT BACKLOG The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum. INCREMENT An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review Source: https://www.scrum.org/resources/what-is-scrum Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact
@arafkarsh arafkarsh Rules of Scrum • Sprint Planning meeting is held at the start of Each Sprint. • Each Sprint must deliver working and fully tested code that demonstrate value to the customer. • Product Owner Prioritizes the Product Backlog. • Team Collectively selects the Amount of Work brought into Sprint • Once a sprint begins, only the team may add to the Sprint backlog. • A Short Scrum meeting is done every day. 76 Source: User Stories Applied by Mike Cohn. Page 204
@arafkarsh arafkarsh What is Kanban 78 Kanban is a method for managing the creation of products with an emphasis on • continual delivery (Daily / Hourly) while • not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively. Kanban is a visual management method that was developed by Toyota in the early 1940s. Kanban in Japanese means Card Microsoft Xbox One Team does multiple Daily releases using Kanban.
@arafkarsh arafkarsh Kanban History 79 Introduced by Toyota in Manufacturing - 1940s It all started in the early 1940s. The first Kanban system was developed by Taiichi Ohno (Industrial Engineer and Businessman) for Toyota automotive in Japan. It was created as a simple planning system, the aim of which was to control and manage work and inventory at every stage of production optimally. Source: https://www.digite.com/kanban/what-is-kanban/ David J. Anderson who was the first to apply the concept to IT, Software development and knowledge work in general in the year 2004.
@arafkarsh arafkarsh Three Principles of Kanban 80 Source: https://resources.collab.net/agile-101/what-is-kanban • Visualize your current workflow: Seeing all items in the context of one another can provide valuable insights. • Limit work in progress (WIP): This approach helps balance the flow-based method, preventing teams from starting and committing to too much work simultaneously. • Improve flow: When a task is completed, the next highest-priority item from the backlog is pulled into action. To Do In Progress Done
@arafkarsh arafkarsh Kanban Board 81 Backlog Work breakdown Work In Progress Done Active Done Active Done Track Task blocked due to Dependency. Once the dependent Task is ready, the blocked Task will be moved to Active State. To Do List Max items in WIP must be 1.4x of total Resources A Backlog item is broken down into tasks, and each Task should take at most 1-3 days at max. It's a good practice to keep all the tasks of similar size. Tasks are assigned to respective team members.
@arafkarsh arafkarsh Similarities between Kanban and Scrum 84 Task Breakdown Continuous Improvement Visible Workflow Both Scrum and Kanban supports Large Complex work to be broken down to smaller tasks and completed efficiently. Both place high focus on Continuous Improvement and process optimization and support a highly visible (Task) Workflows for the visibility to all the stake holders.
@arafkarsh arafkarsh Kanban Vs. Scrum 85 Kanban Scrum Roles & Responsibilities No prescribed roles Pre-defined roles of Scrum master, Product owner and team member Delivery Timelines Continuous Delivery (Daily/Hourly) Time boxed sprints (2-4 Weeks) Delegation & Prioritization Work is pulled through the system (single piece flow) Work is pulled through the system in batches (the sprint backlog) Modifications Changes can be made at any time No changes allowed mid-sprint Measurement of Productivity Cycle time Velocity When to Use? More appropriate in operational environments with a high degree of variability in priority More appropriate in situations where work can be prioritized in batches that can be left alone Source: https://leankit.com/learn/kanban/kanban-vs-scrum/
@arafkarsh arafkarsh Benefits of Kanban 86 • Shorter cycle times can deliver features faster. • Responsiveness to Change: • When priorities change very frequently, Kanban is ideal. • Balancing demand against throughput guarantees that most the customer-centric features are always being worked. • Requires fewer organization / room set-up changes to get started • Reducing waste and removing activities that don’t add value to the team/department/organization • Rapid feedback loops improve the chances of more motivated, empowered and higher-performing team members
@arafkarsh arafkarsh 89 Architecture Styles, Patterns & Design Patterns • Component-based • Client-server • Event-driven • Layered Architecture • Monolithic application • Plug-ins • Publish-subscribe • Service Based • Service-Oriented • Microservices Architecture Style: 1. How to Organize the Code, 2. Creating high-level modules & layers and how they interact each other. Architecture Patterns: A Recurring solution to a recurring problem. Providing the Solution to an Architecture Style. Ex. How a request is processed from the outer layer to inner layer. • Three Tier • Micro Kernel • Model View Controller • Event Sourcing and CQRS • Domain Driven Design Design Patterns: Scope of the Design Patterns is much narrower compared to an Architecture Pattern. It focuses on instantiating an object, behavior of the object. • Adapter • Builder / Factory • Saga • Repository • Aggregate Root Wider Scope Narrow Scope
@arafkarsh arafkarsh Component Based Architecture 90 1. Logical Units: Breaking the App into well defined logical units. 2. Communication: Components communicate using a COM/DCOM, EJB, CORBA, RMI and other protocols or standard API contracts. 3. Reusability: A well defined component can be reused and self deployable unit. 4. Maintenance: Easy to change and upgrade the components without affecting the whole system 5. Ease of Development: With well defined API contracts, it’s easy to develop a component to do a specific task without impacting other parts of the system. 6. Ease of Deployment: It is easy to upgrade the existing version of the component with the latest version without impacting other parts of the system (Provided backward compatibility is maintained).
@arafkarsh arafkarsh o A network separates all the 3 Layers, and by Value, data is transferred. o You can upgrade a layer without worrying about the impact on the other layer as long as the contract between the layers is intact. o The logic Tier can be further divided into 1. Web Services Layer 2. Business Layer 3. Database Layer Layered Architecture Style 91 UI Layer WS BL DL Database Shopping Cart Order Customer Product John J. Donovan developed it in Open Environment Corporation (OEC), a tools company he founded in Cambridge, Massachusetts. 3 Tier Architecture Pattern https://professordonovan.com/open-environment-corporation Presentation Tier UI is the topmost level of the Application. The primary function of the UI is to give a better Human-Machine Interaction. Logic Tier The Logic Tier is the intermediary between the Presentation and Database Tier. Its responsibilities include Interpreting commands, Making logical decisions and evaluations, Performing calculations, and Facilitating the movement and processing of data between the surrounding layers. Database Tier The information is stored and retrieved from the Database Tier. The data is sent back to the Logic Tier for processing and then back to Presentation Tier for the User to take action.
@arafkarsh arafkarsh Service Based Architecture 92 SOA and Microservices based on Service Based Architecture 1. Distributed Computing: Common thing in Service based architecture is distributed computing. 2. Communication: Services communicate using a Remote Access Protocol (SOAP, REST, RMI, JMS, Message Queues, AMQP (Advanced Message Queuing Protocol) 3. Service Contracts: They are based on XML, JSON, ProtoBuf, etc. Contract versioning is a crucial aspect of contracts and their future evolution. 4. Availability and Responsiveness: Availability ensures that there is no single point of failure and Responsiveness ensures that the Service Responds on time. 5. Security: As Services are independent components, security and access controls must be taken care of. JSON Web Token is a popular standard. 6. Transactions: Transaction management is a Big challenge in Service-based Architecture. 2 Phase Commit, or Saga Design Patterns, focus on addressing these challenges.
@arafkarsh arafkarsh SOA – Service Oriented Architecture 93 UI Layer Database Shopping Cart Order Customer Product Enterprise Service Bus Messaging REST / SOAP HTTP MOM JMS ODBC / JDBC Translation Web Services XML WSDL Addressing Security Registry Management Producers Shared Database Consumers 3rd Party Apps Smart Pipes Lot of Business logic resides in the Pipe Traditional Monolithic App with SOA Service properties 1. It logically represents a business activity with a specified outcome. 2. Each Service is self-contained. 3. Each Service is a Blackbox to the Service Consumer. 4. A Service can contain other Services too. 5. Service Can be re-used. For Ex Customer Service can be used by multiple Apps. Source: https://dzone.com/articles/service-oriented-architecture-a-dead-simple-explan
@arafkarsh arafkarsh The microkernel architecture pattern consists of two types of architecture components: 1. a core system and 2. plug-in modules. Application logic is divided between 1. independent plug-in modules 2. and the basic core system, providing 3. extensibility, 4. flexibility, and 5. isolation of application features 6. and custom processing logic Micro Kernel Architecture Pattern 94 Source: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html Plug-In Component Plug-In Component Plug-In Component Core System Plug-In Component Plug-In Component Plug-In Component
@arafkarsh arafkarsh DDD: Bounded Context – Strategic Design 95 • Bounded Context is a Specific Business Process / Concern. • Components / Modules inside the Bounded Context are context specific. • Multiple Bounded Contexts are linked using Context Mapping. • One Team assigned to a Bounded Context. • Each Bounded Context will have it’s own Source Code Repository. • When the Bounded Context is being developed as a key strategic initiative of your organization, it’s called the Core Domain. • Within a Bounded Context the team must have same language called Ubiquitous language for Spoken and for Design / Code Implementation. Domain Driven Design
@arafkarsh arafkarsh 96 User Journey X Bounded Context Bounded Context Bounded Context User Journey Y Bounded Context Bounded Context Bounded Context Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Understanding the Bounded Context (DDD) of an E-Commerce Application. Product Context Order Context Cart Context Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Can we carve out another Microservice from the existing Microservices (Product, Order, Cart)? Monolithic Data Models DDD: App User’s Journey & Bounded Context
@arafkarsh arafkarsh DDD: Understanding Aggregate Root 98 Order Customer Shipping Address Aggregate Root Line Item Line Item Line Item * Payment Strategy Credit Card Cash Bank Transfer Source: Martin Fowler : Aggregate Root • An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. • Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries. • Aggregates are sometimes confused with collection classes (lists, maps, etc.). • Aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain multiple collections, together with simple fields. 125 Domain Driven Design (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
@arafkarsh arafkarsh Event Sourcing Intro 99 Standard CRUD Operations – Customer Profile – Aggregate Root Profile Address Title Profile Created Profile Address New Title Title Updated Profile New Address New Title New Address added Derived Profile Address Notes Notes Removed Time T1 T2 T4 T3 Event Sourcing and Derived Aggregate Root Commands 1. Create Profile 2. Update Title 3. Add Address 4. Delete Notes 1 Events 1. Profile Created Event 2. Title Updated Event 3. Address Added Event 4. Notes Deleted Event 2 Profile Address New Title Current State of the Customer Profile 3 Snapshot Event store Single Source of Truth Greg Young
@arafkarsh arafkarsh 100 Event Sourcing & CQRS (Command and Query Responsibility Segregation) Presentation Tier Logic Tier • Request Validations • Commands / Domain Logic • Data Persistence Database Tier The same Schema is used for both Read and Write. Read Model Write Model Queries (DTOs) Presentation Tier Logic Tier • Request Validations • Commands / Domain Logic • Data Persistence Database Tier Read & Write Schema are different Separate Process Updates the Read DB Write Model Queries (DTOs) Read Model • In traditional data management systems, both commands (updates to the data) and queries (requests for data) are executed against the same entities in a single data repository. • CQRS is a pattern segregating the operations that read data (Queries) from the operations that update data (Commands) using separate interfaces. • CQRS should only be used on specific portions of a system in Bounded Context (in DDD). • CQRS should be used along with Event Sourcing. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx | Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html Axon Framework For Java Java Axon Framework Resource : http://www.axonframework.org CQS: Bertrand Meyer Greg Young
@arafkarsh arafkarsh API Architecture Maturity Levels 102 Source: https://www.apiscene.io/lifecycle/7-layers-of-api-architecture-maturity/ • REST & gRPC – API Communication in Microservices: https://www.apiscene.io/lifecycle/rest-grpc-api-communication-in-microservices/ • A Postman API Governance Collection: https://www.apiscene.io/lifecycle/a-postman-api-governance-collection/ • Impact of Distributed Architecture to API Lifecycle: https://www.apiscene.io/lifecycle/what-is-the-impact-of-distributed-architecture-to-api-lifecycle/ •
@arafkarsh arafkarsh Composable Enterprise Architecture 105 A composable enterprise is an organisation that delivers business outcomes and adapts to the pace of business change. It does this through the assembly and combination of Packaged Business Capabilities (PBCs). PBCs are application building blocks that have been purchased or developed. Source: Gartner: Future of Applications: Delivering the Composable Enterprise | Why does it matter? APIs Event Channels Composable Enterprise Business Capabilities Business Capabilities Business Ecosystems My Application Experience Digital Business Technology Platform Source: Gartner Future of Applications
@arafkarsh arafkarsh Composable Enterprise Architecture 106 Source: Gartner: Future of Applications: Delivering the Composable Enterprise | Why does it matter? On Demand Scalability Service & Apps Integrated with Clients & Devices Automated On Demand Services Self Service Options for App & Data MASA Mesh App & Service Architecture Enterprise Data Available, Accessible, & Integrated into Data Flow Delivers > Packaged Business Capabilities
@arafkarsh arafkarsh Ubiquitous Language Vocabulary shared by all involved parties Used in all forms of spoken / written communication Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Restaurant Context – Food Item : Eg. Food Item (Navrathnakurma) can have different meaning or properties depends on the context. • In the Menu Context it’s a Veg Dish. • In the Kitchen Context it’s is recipe. • And in the Dining Context it will have more info related to user feed back etc. DDD: Ubiquitous Language: Strategic Design 108 As an Restaurant Owner I want to know who my Customers are So that I can serve them better Role-Feature-Reason Matrix BDD – Behavior Driven Development Given Customer John Doe exists When Customer orders food Then Assign customer preferences as Veg or Non Veg customer BDD Construct
@arafkarsh arafkarsh Bounded Context – Strategic Design 109 • Bounded Context is a Specific Business Process / Concern. • Components / Modules inside the Bounded Context are context specific. • Multiple Bounded Contexts are linked using Context Mapping. • One Team assigned to a Bounded Context. • Each Bounded Context will have it’s own Source Code Repository. • When the Bounded Context is being developed as a key strategic initiative of your organization, it’s called the Core Domain. • Within a Bounded Context the team must have same language called Ubiquitous language for Spoken and for Design / Code Implementation.
@arafkarsh arafkarsh DDD: App User’s Journey & Bounded Context 110 An e-Comm App User’s Journey can run across multiple Bounded Context / Microservices. User Journey X Bounded Context Bounded Context Bounded Context User Journey Y Bounded Context Bounded Context Bounded Context Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Understanding Bounded Context (DDD) of a e-Commerce App Product Context Order Context Cart Context Source: Domain-Driven Design Reference by Eric Evans Domain Driven Design Product Catalogue Reviews Product Order Item Shipping Methods Address Payments Order Items Category Inventory Event Cart Items Wish List Price Event Category Order Added From Cart uses uses Can we carve out another Microservice from the existing Microservices?
@arafkarsh arafkarsh DDD: Bounded Context – Strategic Design 111 An App User’s Journey can run across multiple Bounded Context / Micro Services. Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Prepared By Menu uses uses Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Prepared By Menu uses uses Understanding Bounded Context (DDD) of a Restaurant App Dinning Context Kitchen Context Menu Context Source: Domain-Driven Design Reference by Eric Evans Areas of the domain treated independently Discovered as you assess requirements and build language Bounded Context Bounded Context Bounded Context User Journey X
@arafkarsh arafkarsh DDD : Understanding Bounded Context Source: Patterns, Principles and Practices of DDD – Page 124 This model shows multiple responsibilities of the shared Model – Product. This is a classic example of Big Ball of Mud. 112
@arafkarsh arafkarsh DDD : Understanding Bounded Context Source: Patterns, Principles and Practices of DDD – Page 127 Each of this context will become a Microservice 113
@arafkarsh arafkarsh DDD : Understanding Bounded Context Source: BoundedContext By Martin Fowler : http://martinfowler.com/bliki/BoundedContext.html • DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships. • Bounded Contexts have both unrelated concepts • Such as a support ticket only existing in a customer support context • But also share concepts such as products and customers. • Different contexts may have completely different models of common concepts (Customer & Product) with mechanisms to map between these polysemic concepts for integration. 114
@arafkarsh arafkarsh Customer Model in Different Bounded Context 115 Order Customer • Customer ID • Discount • Bonus Program Delivery Customer • Customer ID • Address • Preferred Delivery method • Packaging • Delivery Contact Billing Customer • Customer ID • Billing Address • Payment Type • Tax o Customer Model has different attributes in different contexts. So it avoids storing all the customer info in one place and then sharing that across multiple Bounded Contexts (Microservices). o If you want to change Customer details related to Tax then only Billing Bounded Context (Microservice) needs to be updated.
@arafkarsh arafkarsh DDD : Understanding Bounded Context Source: Patterns, Principles and Practices of DDD – Page 132 Each of this Bounded Context will become a Microservice Communication across Bounded Context Source: Patterns, Principles and Practices of DDD – Page 203 116
@arafkarsh arafkarsh Hexagonal Architecture Ports & Adapters The layer between the Adapter and the Domain is identified as the Ports layer. The Domain is inside the port, and adapters for external entities are outside the port. The notion of a “port” invokes the OS idea that any device that adheres to a known protocol can be plugged into a port. Similarly, many adapters may use the Ports. Source : http://alistair.cockburn.us/Hexagonal+architecture https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net Services for UI Ports File system Database Order Tracking JPA Repository Implementation Adapters OrderProcessing Domain Service (Business Rules) Implementation Domain Models Domain Layer Order Data Validation OrderService REST Service Implementation OrderProcessing Interface p Order Tracking Repository Interface p A A External Apps A A A Others A A OrderService Interface p Web Services External Connectors Business Services Data Store Use Case Boundary Bounded Context A • Reduces Technical Debt • Dependency Injection • Auto Wiring 119
@arafkarsh arafkarsh How? Focus on Core Complexity & Opportunity in the Domain Explore models in collaboration of Domain Experts & Software Experts Write software that expresses these Models explicitly Speak Ubiquitous Language within a Bounded Context 122 Eric Evans – Explore DDD, Denver, 2017
@arafkarsh arafkarsh How? Identity the areas of the business which is critical for the success of the business. Why are these areas important? Why can't we buy a solution rather than building it? What makes the system worth building it? Core Domain 124 Look at the Core Domain as a Product instead of a Project
@arafkarsh arafkarsh How? Supporting Domains are the domains that helps the Core Domain. In an E-Commerce application like Amazon or Flipkart, product search functionality is a supporting domain. Even off the shelf application can be used in a supporting domain, For Ex. Ticketing system. Supporting Domains 125
@arafkarsh arafkarsh Domain Vs. Domain Model 128 Source: Patterns, Principles and Practices of DDD – Page 43 o Analysis Model or Business Model is to describe the Problem space / Domain. o The Domain Model contains only what is relevant to solve the problem. o Domain Model MUST be free of technical complexities.
@arafkarsh arafkarsh Domain Model 129 A domain Model is not a particular diagram; it is the idea the diagram intends to convey. - Eric Evans Domain Model: An object of the Domain that incorporates both behaviour and data. - Martin Fowler
@arafkarsh arafkarsh Indicators for Discovering Bounded Context Identify the Business Capabilities from the User Activities / Stories / Use Cases Based on Activities: If an area within the system contains a set of exclusive activities then that’s an indicator for a Business Capabilities. Based on Trigger: Any area which gets automatically triggered based on external input and does some activities based on that trigger. Ex. Spam Checker, Virus Checker in mail attachments. 130
@arafkarsh arafkarsh List Core Activities 132 o List Code Activities for the Primary Use Case o Identify the Business Function / Capabilities of each of the Activity o Identify the User Role (Actor) for this Activity, o Ensure that the list of the Activities complete the entire Business Solution. Activity Business Function Actor 1 2 3 4 5 6 7 8 9 10
@arafkarsh arafkarsh DDD : Understanding Context Map 1. A context map provides Global View of the system that UML or architecture diagrams completely miss, helping us to focus on choices that are really viable in your scenario without wasting money. 2. Each Bounded Context fits within the Context Map to show how they should communicate amongst each other and how data should be shared. 135 Up Stream (u) – Down Stream (d) The upstream team may succeed independently of the fate of the downstream team. Mutually Dependent Success depends on the success of both the teams. Free In which success or failure of the development work in other contexts has little affect on delivery.
@arafkarsh arafkarsh DDD: Context Map 136 Term Definition Action Partnership When teams in two context will succeed or fail together, a cooperative relationship often emerges. Forge Partnerships Shared Kernel Sharing a part of the Mode and associated code is very intimate interdependency, which can leverage design work or undermine it. Keep the Kernel Small. Customer / Supplier When two teams are in upstream – downstream relationship, where the upstream team may succeed independently of the fate of the downstream team, the needs of the downstream come to be addressed in a variety of ways with wide range of consequences. Downstream priorities factor into upstream planning. Conformist Upstream has no motivation in this partnership to keep the promise. Altruism may motivate Upstream developers to give promises they cant keep. Share just enough info with upstream to keep their motivation. Anti Corruption Layer When the translation between two bounded context becomes more complex, then the translation layer takes on a more defensive tone. (down stream) creates a layer in sync own model and matching (up stream) functionality.
@arafkarsh arafkarsh DDD: Context Map 137 Term Definition Action Open Host Service When a subsystem has to be integrated with many others, customizing a translator for each can bog down the team. There is more and more to maintain, and more and more to worry about when changes are made. Use a one of translator to augment the Protocol to share info (REST) Published Language Translation between the models of two bounded contexts requires a common language. Published Language is often combined with Open Host Service. Use a well documented shared language (JSON) Separate Ways If two sets of functionality have no significant relationship, they can be completely cut loose from each other. Integration is always expensive and sometimes the benefit is small. Bounded context with no connection to others. Big Ball of Mud As we survey existing systems, we find that, in fact, there are parts of systems, often large ones, where models are mixed and boundaries are inconsistent. Designate the mess as a Big Ball of Mud.
@arafkarsh arafkarsh DDD: Strategic Design Patterns 139 Pattern Description Page 1 Bounded Context They are NOT Modules A Bounded Context delimits the applicability of a particular model so that the team members have a clear and shared understanding of what has to be consistent and how it relates to other Contexts. Contexts can be created from (but not limited to) the following: • how teams are organized • the structure and layout of the code base • usage within a specific part of the domain 335 2 Context Map Context mapping is a design process where the contact points and translations between bounded contexts are explicitly mapped out. Focus on mapping the existing landscape, and deal with the actual transformations later. 1. Shared Kernel 2. Customer / Supplier 3. Conformist 4. Anti Corruption Layer 5. Separate Ways 3 Specification Pattern Use the specification pattern when there is a need to model rules, validation and selection criteria. The specification implementations test whether an object satisfies all the rules of the specification. 4 Strategy Pattern The strategy pattern, also known as the Policy Pattern is used to make algorithms interchangeable. In this pattern, the varying 'part' is factored out. 5 Composite Pattern This is a direct application of the GoF pattern within the domain being modeled. The important point to remember is that the client code should only deal with the abstract type representing the composite element. Page Number from Domain Driven Design – Published in 2015
@arafkarsh arafkarsh Common Problems 140 1. Trying to make a perfect Boundary for the Context. 2. Overemphasizing the importance of Tactical Design Patterns 3. Using the same architecture for all Bounded Contexts 4. Neglecting the Strategic Design Patterns 5. Focusing on Code rather than the principles of DDD
@arafkarsh arafkarsh Domain Driven Design • Strategic Design • Tactical Design o Entity o Value Object o Aggregate Root o Factory o Repository o Domain Service o Domain Events 141
@arafkarsh arafkarsh Layered Architecture 143 • Explicit Domain Models – Isolate your models from UI, Business Logic. • Domain Objects – Free of the Responsibility of displaying themselves or storing themselves or managing App Tasks. • Zero Dependency on Infrastructure, UI and Persistent Layers. • Use Dependency Injection for Loosely Coupled Objects. • All the Code for Domain Model in a Single Layer. • Domain Model should be Rich enough to represent Business Knowledge. Source: DDD Reference by Chris Evans Page 17
@arafkarsh arafkarsh Entity 144 Entities are Domain Concepts with Identity and Continuity and can be stored in a database. Identity Examples of an Entity • Order ID in Order Entity • Social Security Number in Person Entity Entity • Order (Aggregate Root) • Order ID • Order Item Array • Payment • Shipping Address • Order Item • Payment • Total Payment
@arafkarsh arafkarsh Value Objects 145 Value Object • Shipping Address • Name • Street • City • State • Country • Item Value • Amount • Currency • Audit Log • Time • User • IP Address It Represent a specific business concept related that Bounded Context. Value objects doesn’t have any specific identity. It exists as part of an Entity and stored along with Entity. • Currency • USD • INR EURO • POUND • Order Status • IN PROGRESS • IN TRANSIT • DELIVERED • Payment Type • CREDIT CARD • DEBIT CARD • Record State Embeddable Object Enumeration
@arafkarsh arafkarsh Understanding Aggregate Root 146 Order Customer Shipping Address Aggregate Root Line Item Line Item Line Item * Payment Strategy Credit Card Cash Bank Transfer Source: Martin Fowler : Aggregate Root • An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. • Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries. • Aggregates are sometimes confused with collection classes (lists, maps, etc.). • Aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain multiple collections, together with simple fields. 125 Domain Driven Design (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
@arafkarsh arafkarsh Designing and Fine-Tuning Aggregate Root 147 Source : Effective Aggregate Design Part 1/2/3 : Vaughn Vernon http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf Aggregate Root - #1 Aggregate Root - #2 Super Dense Single Aggregate Root Results in Transaction concurrency issues. Super Dense Aggregate Root is split into 4 different smaller Aggregate Root in the 2nd Iteration. Working on different design models helps the developers to come up with best possible design. (C) COPYRIGHT METAMAGIC GLOBAL INC., NEW JERSEY, USA
@arafkarsh arafkarsh Rules for Building Aggregate Roots 1. Protect True Invariants in Consistency Boundaries. This rule has the added implication that you should modify just one Aggregate instance in a single transaction. In other words, when you are designing an Aggregate composition, plan on that representing a transaction boundary. 2. Design Small Aggregates. The smallest Aggregate you can design is one with a single Entity, which will serve as the Aggregate Root. 3. Reference Other Aggregates Only By Identity. 4. Use Eventual Consistency Outside the Consistency Boundary. This means that ONLY ONE Aggregate instance will be required to be updated in a single transaction. All other Aggregate instances that must be updated as a result of any one Aggregate instance update can be updated within some time frame (using a Domain Event). The business should determine the allowable time delay. 5. Build Unidirectional Relationship from the Aggregate Root. 148
@arafkarsh arafkarsh Domain Services 149 Domain Services focuses bringing the Behavior to your Domain involving Entities and Value Objects. It focuses on a Single Responsibility. Implementation of the Domain Service resides in the service layer (Adapters) and not in the Domain Layer. Domain Layer • Models • Repo • Services • Factories Adapters • Repo • Services • Web Services Service Layer
@arafkarsh arafkarsh Domain Events & Integration Events 150 1. Domain Events represent something happened in a specific Domain. 2. Domain Events should be used to propagate STATE changes across Multiple Aggregates within the Bounded Context. 3. The purpose of Integration Events is to propagate committed transactions and updates to additional subsystems, whether they are other microservices, Bounded Contexts or even external applications. Source: Domain Events : Design and Implementation – Microsoft Docs – May 26, 2017 Domain Data Behavior Order (Aggregate Root) Data Behavior Address (Value Object) Data Behavior OrderItem (Child) 1 n 1 1 Order Created Domain Event Domain Layer Enforce consistency with other Aggregates Event Handler 1 Event Handler n Create and Publish Integration Event to Event Bus. Example: Order Placed Integration Event can be subscribed by Inventory system to update the Inventory details. Event Handler 2
@arafkarsh arafkarsh Reactive Programming Comparison : Iterable / Streams / Observable 153 First Class Visitor (Consumer) Serial Operations Parallel Streams (10x Speed) Still On Next, On Complete and On Error are Serial Operations Completely Asynchronous Operations Java 8 – Blocking Call Java 6 – Blocking Call Rx Java - Freedom
@arafkarsh arafkarsh Reactive Programming RxJava Operator : Filter / Sort / FlatMap 154 Objective: toSortedList() returns an Observable with a single List containing Fruits. Using FlatMap to Transform Observable to Observable Rx Example 2
@arafkarsh arafkarsh Data Transfer Object vs. Value Object 155 Data Transfer Object Value Object A DTO is just a data container which is used to transport data between layers and tiers. A Value Object represents itself a fix set of data and is similar to a Java enum. It mainly contains of attributes and it’s a serializable object. A Value Object doesn't have any identity, it is entirely identified by its value and is immutable. DTOs are anemic in general and do not contain any business logic. A real world example would be Color.RED, Color.BLUE, Currency.USD Patterns of Enterprise Application Architecture : Martin Fowler http://martinfowler.com/books/eaa.html A small simple object, like money or a date range, whose equality isn’t based on identity. 486 P of EAA Java EE 7 Retired the DTO In Java EE the RS spec became the de-facto standard for remoting, so the implementation of serializable interface is no more required. To transfer data between tiers in Java EE 7 you get the following for FREE! 1. JAXB : Offer JSON / XML serialization for Free. 2. Java API for JSON Processing – Directly serialize part of the Objects into JSON
@arafkarsh arafkarsh DTO – Data Transfer Object • Security Considerations • Data obtained from untrusted sources, such as user input from a Web page, should be cleansed and validated before being placed into a DTO. Doing so enables you to consider the data in the DTO relatively safe, which simplifies future interactions with the DTO. 156 The Problem Assembler Pattern An object that carries data between processes in order to reduce the number of method calls. Benefits 1. Reduced Number of Calls 2. Improved Performance 3. Hidden Internals 4. Discovery of Business objects Liabilities 1. Class Explosion 2. Additional Computation 3. Additional Coding Effort https://msdn.microsoft.com/en-us/library/ms978717.aspx Problem: How do you preserve the simple semantics of a procedure call interface without being subject to the latency issues inherent in remote communication? The Solution 401 P of EAA
@arafkarsh arafkarsh DTO – Data Transfer Object 157 An object that carries data between processes in order to reduce the number of method calls. The most misused pattern in the Java Enterprise community is the DTO. DTO was clearly defined as a solution for a distribution problem. DTO was meant to be a coarse-grained data container which efficiently transports data between processes (tiers). On the other hand considering a dedicated DTO layer as an investment, rarely pays off and often lead to over engineered bloated architecture. Real World Java EE Patterns Adam Bien http://realworldpatterns.com Don't underestimate the cost of [using DTOs].... It's significant, and it's painful - perhaps second only to the cost and pain of object- relational mapping. Another argument I've heard is using them in case you want to distribute later. This kind of speculative distribution boundary is what I rail against. Adding remote boundaries adds complexity. One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model. In this case it makes sense to make presentation specific facade/gateway that maps from the domain model and presents an interface that's convenient for the presentation. Patterns of Enterprise Application Architecture : Martin Fowler http://martinfowler.com/books/eaa.html 401 P of EAA
@arafkarsh arafkarsh Repository Pattern • Objectives • Use the Repository pattern to achieve one or more of the following objectives: • You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing. • You access the data source from many locations and want to apply centrally managed, consistent access rules and logic. • You want to implement and centralize a caching strategy for the data source. • You want to improve the code's maintainability and readability by separating business logic from data or service access logic. • You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time. • You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity. • You want to apply a domain model to simplify complex business logic. 159 Repository Pattern Source: Martin Fowler : http://martinfowler.com/eaaCatalog/repository.html | Microsoft : https://msdn.microsoft.com/en-us/library/ff649690.aspx Mediates between the domain and data mapping layers using a collection- like interface for accessing domain objects. 322 P of EAA Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.
@arafkarsh arafkarsh Anemic Domain Model : Anti Pattern • There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. • The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. • The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. • The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. 160 Source: Anemic Domain Model By Martin Fowler : http://martinfowler.com/bliki/AnemicDomainModel.html • lockUser() • unlockUser() • addAddress(String address) • removeAddress(String address)
@arafkarsh arafkarsh Procedural Design Vs. Domain Driven Design 161 1. Anemic Entity Structure 2. Massive IF Statements 3. Entire Logic resides in Service Layer 4. Type Dependent calculations are done based on conditional checks in Service Layer 4 1 2 3 Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html Domain Driven Design with Java EE 6 By Adam Bien | Javaworld
@arafkarsh arafkarsh Polymorphic Business Logic inside a Domain object 162 Domain Driven Design with Java EE 6 By Adam Bien | Javaworld Computation of the total cost realized inside a rich Persistent Domain Object (PDO) and not inside a service. This simplifies creating very complex business rules. Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html
@arafkarsh arafkarsh Type Specific Computation in a Sub Class 163 Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html We can change the computation of the shipping cost of a Bulky Item without touching the remaining classes. Its easy to introduce a new Sub Class without affecting the computation of the total cost in the Load Class. Domain Driven Design with Java EE 6 By Adam Bien | Javaworld of
@arafkarsh arafkarsh Object Construction : Procedural Way Vs. Builder Pattern 164 Procedural Way Builder Pattern Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html Domain Driven Design with Java EE 6 By Adam Bien | Javaworld
@arafkarsh arafkarsh DDD: Tactical Design Patterns 165 Pattern Description Page 6 Entity An object defined Primarily by its identity is called an Entity 91 - Value Object (Already referred in P of EAA) Many Objects have no conceptual Identity. These objects describe the characteristic of a thing. 97 7 Aggregate Aggregate is a cluster of domain objects that can be treated as a Single Unit. Example Order and Order Item. 125 Aggregate Root An Aggregate will have one of its component object be the Aggregate Root. 127 - Repositories (Already referred in P of EAA) A Repository represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capabilities. Objects of appropriate type are added and removed, and the machinery behind the Repository inserts them or deletes them from the database. This definition gathers a cohesive set of responsibilities for providing access to the roots of Aggregates from early life cycle through the end. 147 8 Factory / Builder Pattern When creation of an Object, or an entire Aggregate, becomes complicated or reveals too much of the internal structure, Factories provides encapsulation. 136 Page Number from Domain Driven Design – Published in 2015
@arafkarsh arafkarsh DDD: Tactical Design Patterns 166 Pattern Description Page 9 Factory / Builder Pattern When creation of an Object, or an entire Aggregate, becomes complicated or reveals too much of the internal structure, Factories provides encapsulation. 136 10 Domain Service A Service tends to be named of an Activity rather than an Entity. 1. The Operation relates to a domain concept that is not a natural part of an Entity. 2. The interface is defined in terms of other elements of the Domain Model 3. The operation is stateless 104 11 Anti – Corruption Layer (External Integration) Creating an isolating layer to provide clients with functionality in terms of their own Domain Model. The layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally the Layer translates in both directions as necessary between the two models. 365 12 Domain Events A Domain Event is a full-fledged part of the Domain Model, a representation of of something that happened in the Domain. Explicit events that the domain experts wants to track and notified of or which are associated with the state changes in other Domain Models. Page Number from Domain Driven Design – Published in 2015
@arafkarsh arafkarsh Shopping Portal Design based on Hexagonal Architecture 168 Monolithic App Design using DDD Domain Driven Design helps you to migrate your monolithic App to Microservices based Apps
@arafkarsh arafkarsh Shopping Portal 169 Order Context Models Value Object • Shipping Address • Currency • Item Value • Order Status • Payment Type • Record State • Audit Log Entity • Order (Aggregate Root) • Order Item • Payment DTO • Order • Order Item • Shipping Address • Payment Domain Layer Adapters • Order Repository • Order Service • Order Web Service • Order Query Web Service • Shipping Address Web Service • Payment Web Service Adapters Consists of Actual Implementation of the Ports like Database Access, Web Services API etc. Converters are used to convert an Enum value to a proper Integer value in the Database. For Example, Order Status Complete is mapped to integer value 100 in the database. Services / Ports • Order Repository • Order Service • Order Web Service Utils • Order Factory • Order Status Converter • Record State Converter • Order Query Web Service • Shipping Address Web Service • Payment Web Service
@arafkarsh arafkarsh RESTful Guidelines 172 1. Endpoints as nouns, NOT verbs Ex. /catalogues /orders /catalogues/products and NOT /getProducts/ /updateProducts/ 2. Use plurals Ex. /catalogues/{catalogueId} and NOT /catalogue/{catalogueId} 3. Documenting 4. Paging 5. Use SSL 6. HTTP Methods GET / POST / PUT / DELETE / OPTIONS / HEAD 7. HTTP Status Codes (Effective usage) 8. Versioning Media Type Version GET /account/5555 HTTP/1.1 Accept: application/vnd.catalogues.v1+json URL path version https://domain/v1/catalogues/products
@arafkarsh arafkarsh RESTful Guidelines – Query Examples 173 Search All Products Search Products By Catalogue ID Search Products By Catalogue ID & Product ID
@arafkarsh arafkarsh 175 # Name * Who Uses Pros Cons 1 Media Type Versioning Accept: Application/vnd.api.article+xml; version=1.0 Med GitHub • Version Directly @ resource level • Preserve URI • Close to RESTful Specs • Harder to Test • Distort HTTP Headers purpose • Tools required for testing 2 Custom Headers Versioning X-API-Version: 2. Med Microsoft • Preservers URI • Harder to Test • Tools required for testing 3 URI Versioning api.example.com/v1/resource High Google Twitter Amazon • Most common method • Versions can be explored using Browser • Easy to use • Disrupts RESTful Compliance. URI should represent resource and not versions 4 Domain Versioning apiv1.example.com/resource Low Facebook • Same as are URI Versioning • Same as URI Versioning 5 Request Parameter Versioning GET /something/?version=0.1 High Pivotal NetFlix • Similar to URI versioning • It can get messy 6 Date Versioning First request saves the date. Low Clearbit • New APIs can be shipped without changing the end points • Complex to implement • Traceability is difficult. API Versioning
@arafkarsh arafkarsh Restful API Summary 185 o Endpoints as Nouns not VERBS o /catalogues, /orders, /products/category o API Versioning o Use the best suited to your environment o Use all the HTTP Verbs o GET, POST, PUT, DELETE
@arafkarsh arafkarsh 186 100s Microservices 1,000s Releases / Day 10,000s Virtual Machines 100K+ User actions / Second 81 M Customers Globally 1 B Time series Metrics 10 B Hours of video streaming every quarter Source: NetFlix: : https://www.youtube.com/watch?v=UTKIT6STSVM 10s OPs Engineers 0 NOC 0 Data Centers So what do NetFlix think about DevOps? No DevOps Don’t do lot of Process / Procedures Freedom for Developers & be Accountable Trust people you Hire No Controls / Silos / Walls / Fences Ownership – You Build it, You Run it.
@arafkarsh arafkarsh 187 50M Paid Subscribers 100M Active Users 60 Countries Cross Functional Team Full, End to End ownership of features Autonomous 1000+ Microservices Source: https://microcph.dk/media/1024/conference-microcph-2017.pdf 1000+ Tech Employees 120+ Teams
@arafkarsh arafkarsh References 193 1. July 15, 2015 – Agile is Dead : GoTo 2015 By Dave Thomas 2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google 3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head 4. Feb 17, 2019 - Lean vs Agile vs Design Thinking 5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban 6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained. Agile Methodologies
@arafkarsh arafkarsh References 195 Microservices 1. Microservices Definition by Martin Fowler 2. When to use Microservices By Martin Fowler 3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler 4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern 5. Thought Works: Microservices in a Nutshell 6. Microservices Prerequisites 7. What do you mean by Event Driven? 8. Understanding Event Driven Design Patterns for Microservices
@arafkarsh arafkarsh References – Microservices – Videos 196 1. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 4. GOTO 2015 – Challenges Implementing Micro Services By Fred George 5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 17. GOTO 2017 – Microservices without Servers. By Glynn Bird.
@arafkarsh arafkarsh References 197 Domain Driven Design 1. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans 2. Mar 19, 2013 Domain Driven Design By Eric Evans 3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune 8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans 9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans 10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner
@arafkarsh arafkarsh References 198 Event Sourcing and CQRS 1. IBM: Event Driven Architecture – Mar 21, 2021 2. Martin Fowler: Event Driven Architecture – GOTO 2017 3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016 4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS 6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes
@arafkarsh arafkarsh References 200 Databases: Big Data / Cloud Databases 1. Google: How to Choose the right database? 2. AWS: Choosing the right Database 3. IBM: NoSQL Vs. SQL 4. A Guide to NoSQL Databases 5. How does NoSQL Databases Work? 6. What is Better? SQL or NoSQL? 7. What is DBaaS? 8. NoSQL Concepts 9. Key Value Databases 10. Document Databases 11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends 12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012 13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB 14. Oct 30, 2020 - Column vs Row Oriented Databases Explained 15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained! 1. Graph Databases 2. Column Databases 3. Row Vs. Column Oriented Databases 4. Database Indexing Explained 5. MongoDB Indexing 6. AWS: DynamoDB Global Indexing 7. AWS: DynamoDB Local Indexing 8. Google Cloud Spanner 9. AWS: DynamoDB Design Patterns 10. Cloud Provider Database Comparisons 11. CockroachDB: When to use a Cloud DB?
@arafkarsh arafkarsh References 202 1. Feb 6, 2020 – An introduction to TDD 2. Aug 14, 2019 – Component Software Testing 3. May 30, 2020 – What is Component Testing? 4. Apr 23, 2013 – Component Test By Martin Fowler 5. Jan 12, 2011 – Contract Testing By Martin Fowler 6. Jan 16, 2018 – Integration Testing By Martin Fowler 7. Testing Strategies in Microservices Architecture 8. Practical Test Pyramid By Ham Vocke Testing – TDD / BDD
@arafkarsh arafkarsh 203 1. Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and most of the important components are plug- gable. 2. Pumba : A chaos testing and network emulation tool for Docker. 3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH- managed environment, as an aid to resilience testing of high-availability systems. 4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours. 5. Blockade : Docker-based utility for testing network failures and partitions in distributed applications. 6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server. 7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift components like Pods or Deployment Configs and randomly terminates them. 8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS deployed to an Azure Resource Manager-based resource group. 9. Tugbot : Testing in Production (TiP) framework for Docker. Testing tools
@arafkarsh arafkarsh References 204 CI / CD 1. What is Continuous Integration? 2. What is Continuous Delivery? 3. CI / CD Pipeline 4. What is CI / CD Pipeline? 5. CI / CD Explained 6. CI / CD Pipeline using Java Example Part 1 7. CI / CD Pipeline using Ansible Part 2 8. Declarative Pipeline vs Scripted Pipeline 9. Complete Jenkins Pipeline Tutorial 10. Common Pipeline Mistakes 11. CI / CD for a Docker Application
@arafkarsh arafkarsh References 206 1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Zuul Edge Server, Ketan Gote, May 22, 2017 10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017 11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017 12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017 13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016 15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015
arafkarsh
segavvy
peisuke
minorun365
taichinakamura
el_stoffel
shunsukeono_am
cmusudakeisuke
lambda
pkshadeck
hanayo04
k1style
fullfull
keavy
zenorocha
michaelherold
62gerente
mza
chrisshort
myddelton
akmur
trallard
speakerdeck
paigeccino
colly