of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 1 Design Thinking / Lean Startup Agile (Scrum/Kanban) / Epics / User Stories Architecture Styles Domain Driven Design API’s In-Depth / RESTful Open API 3.0 / Swagger Microservice Architecture Series Part 1 of 15 To Build Cloud Native Apps Composable Enterprise Architecture
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.
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
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)
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
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
What might be Definitive Iterative Focus Groups Observation Spreadsheets Stories / Scenarios Individual Responsibility Collaboration Permanent Jobs Temporary Projects 12 Tom Klinkowstein – Professor of Design & New Media, New York
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.
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
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
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
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
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
Solution focuses on the entire Journey of the User, which can run across multiple Microservices. ❑ Business Solution comprises a set of Business Processes. ❑ A specific Microservice functionality will be focused on a Business Process / Concern. ❑ Business Processes can be divided further into Business Functions
/ 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
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
• 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
Outcome Oriented Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html 26 Traditional corporate IT organizations operate in an activity-oriented manner where they fund projects with set time-spans. Organizations that are outcome-oriented align better with business outcomes, but project-based funding undermines long- term effectiveness. Basing funding on products centered around long-term business capabilities creates stable teams that are aligned with business needs. Outcome-oriented thinking compels business capability centered organizations to consider more than just delivering the scope, which is where we want to be. Project based Product based Activity Oriented Outcome Oriented Business Capability Centric
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
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.
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.
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.
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
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.
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
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.
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
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
communication. • User stories are comprehensible by everyone. • User stories are the right size for planning. • User stories work for iterative development. • User stories encourage deferring detail. • User stories support opportunistic design. • User stories encourage participatory design. • User stories build up tacit knowledge. 38 Source: User Stories Applied by Mike Cohn. Page 178
want the system to automatically switch to a backup data centre in the event of a failure, So that services are restored quickly and data loss is minimised. Role-Feature-Reason Matrix User Story - 1: Disaster Recovery BDD Acceptance Criteria – 1: Failure Given a major data centre failure When the system detects the failure Then it must automatically failover to a secondary data centre with minimal service disruption. BDD Acceptance Criteria – 2 : RPO / RTO Given the system has failed over to a secondary data centre, When recovery processes are initiated, Then The Recovery Point Objective (RPO) must not exceed 5 minutes AND the Recovery Time Objective (RTO) must not exceed 30 minutes. BDD Acceptance Criteria – 3 : Data Loss Given a data recovery process, When data is restored, Then data loss must not exceed the last 5 minutes of data prior to the disruption.
want the system to maintain operational capability during component failures, So that business processes can continue without interruption. Role-Feature-Reason Matrix User Story - 2: Business Continuity BDD Acceptance Criteria – 1: Failure Given a failure in one of the main operational components, When the failure occurs, Then the system must continue operations using redundant components without manual intervention. BDD Acceptance Criteria – 2 : Data Given the system is operating under failure conditions, When data is being processed, Then it should synchronize in real-time with backup components to maintain data integrity.
officer, I want the system to adhere to data encryption standards and enforce strict access controls, So that the system remains compliant with GDPR and other privacy laws. Role-Feature-Reason Matrix User Story - 3: Security & Compliance BDD Acceptance Criteria – 1: Data Given data storage and transfer processes, When data is handled by the system, Then all personal data must be encrypted both at rest and in transit using industry-standard methods. BDD Acceptance Criteria – 2 : Authorization / Log Given any access request to sensitive data, When the request is processed, Then the system must enforce role-based access controls AND log the activity in the audit trail.
I want the system to achieve 99.99% uptime, So that customers can reliably access our services at any time. Role-Feature-Reason Matrix User Story - 4: High Availability BDD Acceptance Criteria – 1 : Failure Given an instance of server failure, When the failure is detected, Then the system must automatically reroute traffic to active instances without user impact. BDD Acceptance Criteria – 2 : Upgrades Given maintenance or update procedures, When these procedures are executed, Then they must not affect the availability of the system.
want the system to handle up to 1 million concurrent users efficiently, So that the performance remains stable as the user base grows. Role-Feature-Reason Matrix User Story - 5: Load & Scalability BDD Acceptance Criteria – 1 : Load Given an increase in user load to the system, When the number of active users approaches 1 million, Then the system must automatically scale resources to maintain performance. BDD Acceptance Criteria – 2 : Scalability Given a quarterly scalability test, When the test is conducted, Then the system must demonstrate its ability to maintain response times under high load conditions.
the application to load quickly and respond rapidly to my inputs, So that my experience is efficient and free from frustrating delays. Role-Feature-Reason Matrix User Story - 6: App Performance BDD Acceptance Criteria – 1 : Performance Given any user action that requires a page load, When the page is accessed, Then it must load within 3 seconds for 90% of attempts under typical load conditions. BDD Acceptance Criteria – 2 : Performance Tx Given any transaction is initiated by the user, When the transaction is processed, Then it must be completed within 2 seconds for 95% of transactions.
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
53 1. Register 3. Make Appointment 4. Diagnosis and Prescription 6. Get Medicine 5. Lab Tests Health Staff Appointment Pharmacy Lab Diagnosis 2. Search & Select Doctor Patient User Journey Minimum Viable Product Upload Medical Docs Add Doctor / Nurse Cancel Appointment R2 Lab Tests View Medical History Duty Calendar R3 Reschedule Register Search Doctor Available Dates Book Appointment Medical History Check Verify Prescription Pack Medicines R1 Pre-Checkup Diagnosis & Prescription Appointment Upload Results Schedule Duty Time Make Payment Share Medical Docs R4 Appointment Calendar Make Payment View Appointments Email SMS
Initiative Epic User Story Sprint Digital Banking / Personal Banking 1. Customer Account Mgmt 2. Transaction Mgmt 3. Fraud Detection 4. Notification / Alerts 5. Account Mgmt 6. Authentication 2. Tx Mgmt Release 1 1. Fund Transfer UPI 2. View Tx Release 2 1. Fund Transfer NEFT 2. Fund Transfer IMPS Release 3 1. Fund Transfer RTGS 2. Download Tx Stories 1. Fund Transfer UPI 2. Fund Transfer NEFT 3. Fund Transfer IMPS 4. Fund Transfer RTGS 5. View Tx 6. Download Tx
Link Aadhaar Link Pan Card Add Receiver List Receiver Deactivate User Banking Experience Create Account Set Notification Fund Transfer Validate Tx Set Alerts Add Receiver User Journey EMail SMS Set Alerts Flag Suspicious Tx Notify Customer Block Tx Customer Mgmt Account Mgmt Tx Mgmt Notification Fraud Detection Alerts View Tx Fund Transfer UPI Download Tx Fund Transfer NEFT Fund Transfer IMPS
customer I want to create an account So that I can deposit money, withdraw, and manage my finances. Role-Feature-Reason Matrix User Story – 1 : Customer Registration BDD Acceptance Criteria – 1: Save User Given The fields First Name, Last Name, DOB Address, Email Address, Phone No. When The user enters values in the fields First Name, Last Name, DOB Address, Email Address, and Phone No. Then If the following fields contain values First Name, Last Name, Address, Email Address, and Phone No. AND Age is greater than 18, then Save the Data. BDD Acceptance Criteria – 2 : Generate Password Given User Info Available When The email address is a valid email id. Then Generate the Password AND Send mail with the user email address as login id and the URL of the portal AND Send the Password to a separate email address. AND Store data on mail status as mail sent or failed. BDD Acceptance Criteria – 3 : Resend Mail Given User Registration mail status is available. When The Mail status is equal to "Failed". Then Send the mail again AND store the attempt number.
customer I want to add a Receiver Account So that I can do a Fund Transfer to that account Role-Feature-Reason Matrix User Story – 1 : Add Receiver Account BDD Acceptance Criteria – 1: Save Receiver Given The customer provides valid receiver account details – Name, IFSC Code, Bank Account When The user enters values in the fields Name, IFSC Code, Bank Account Then If the following fields contain values Name, IFSC Code, Bank Account, then Save the Data with a flag saying Pending for OTP Verification. BDD Acceptance Criteria – 2 : Send OTP Given Receiver Info Available When Send the OTP in SMS or Email Then Store OTP for verification by the Customer AND store the Expiry time greater than the Current time, BDD Acceptance Criteria – 3 : OTP Verification Given OTP Number by the Customer When OTP is verified with database AND its valid AND not Expired Then Change the Receiver status to Verified AND the max transaction value allowed for 24 hours is Rs. 50,000/-
I want to Select a Receiver Account So that I can do a Fund Transfer to that account Role-Feature-Reason Matrix User Story – 1 : Fund Transfer BDD Acceptance Criteria – 1: Initiate Fund Transfer Given A customer provides valid receiver details and transfer amount, When they initiate the transfer Then the transaction is processed, AND generates OTP for verification BDD Acceptance Criteria – 2 : Validate Tx Given a transfer amount exceeds the daily limit When the customer initiates the transaction Then The system rejects the transfer with a limit exceeded message. BDD Acceptance Criteria – 3 : OTP Verification Given OTP Number by the Customer When OTP is verified with database AND its valid AND not Expired Then The transaction is processed, and the balances are updated.
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
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
61 Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use PayPal R2 Search by Brand Product Reviews Pay Debit Card R3 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Search by Model Search by Rating R4 Minimum Viable Product
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
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
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.
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.
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.
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."
I want to Add a Product to the Cart So that I can buy the Product Role-Feature-Reason Matrix User Story – 1 : Add to Cart BDD Acceptance Criteria – 1: Add to Cart Given The user logs into the portal, a Product is selected, and Product details are available. When The user then clicks Add to Cart Button. Then The system will add the Item (Product) to the Cart and Update the Item counter in the Cart Icon AND Saves the Cart information in the DB, AND if the save fails, the system shows an Error "Unable to Add Product to the Cart." BDD Acceptance Criteria – 2: Save Cart Given The Request is authenticated. When The Input contains the user login id and Product id. Then The system will add the Item (Product) to the Cart Saves the Cart information in the DB AND if the save fails, the system shows an Error "Unable to Add Product to the Cart."
I want to see all the items in the Cart So that I can buy the Product Role-Feature-Reason Matrix User Story – 2 : Show Cart BDD Acceptance Criteria – 1: Show Cart Given The user logged into the portal. When The user then clicks Cart. Then The system retrieves all the Cart Items from the DB and shows in the UI the following details Product Item Name, Thumb scale picture, Quantity, Price, and Delete Button to delete the item and Sum total of Items and Price. IF the Cart is empty (No Records in the DB), then it shows an Empty Cart with the message "Cart is Empty." BDD Acceptance Criteria – 2: Show Cart Given The Request is authenticated. When The Input contains the user login id. Then The system retrieves all the Cart Items from the DB and shows in the UI the following details. Product Item Name, Thumb scale picture, Quantity, Price IF the Cart is empty (No Records in the DB), then it shows an Empty Cart with the message “Cart is Empty."
I want to Delete a Product from the Cart So that I can buy other items in the Cart. Role-Feature-Reason Matrix User Story – 3 : Delete from Cart BDD Acceptance Criteria – 1: Delete From Cart Given The user logs into the portal and clicks the Shopping Cart, and the cart displays all the items. When The user then clicks Delete Button for a Product. Then The system will delete the Item (Product) from the Cart and update the Item counter in the Cart Icon. AND deletes an item from the Cart DB AND if the delete fails, the system shows an Error" Unable to Delete Product from the Cart." BDD Acceptance Criteria – 2: Delete item Given The Request is authenticated. When The Input contains the user login id and Product id. Then The system will delete the Item (Product) from the cart DB AND if the delete fails, the system shows an Error "Unable to Delete Product from the Cart."
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.
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.
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.
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.
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.
I want to check a Product So that I can buy the Product. Role-Feature-Reason Matrix User Story – 2 : Show Product with Image Gallery BDD Acceptance Criteria – 1: Show Product Given The user logs into the Portal, a Product is searched, and results are available. When The user then clicks a product for product details. Then The System will show product details based on the product ID with the following information. Product Name, Product Rating, Price, Product Description and Image Gallery, and buttons to "Add to Cart" and "Buy Now." If the Product is not available, then the System will show an error "Selected Product details are not available." BDD Acceptance Criteria – 2: Retrieve Product Given The Request is authenticated. When The Input contains the product id. Then The System will return the product details based on the product ID with the following information. Product Name, Product Rating, Price, Product Description, and Image Gallery If the Product is not available, then the System will show an error "Selected Product details not available."
I want to Update the Quantity of a Product in the Cart So that I can buy the Product. Role-Feature-Reason Matrix User Story – 3 : Update the Cart BDD Acceptance Criteria – 1: Update Quantity Given The user logs into the Portal and clicks the Shopping Cart, and the Cart displays all the items. When The user then inputs the Quantity for a Product. Then The System ensures that the Quantity is greater than ZERO AND the System will update the Quantity in the cart DB. AND if there is an error in updating System will show "Unable to update the Quantity." BDD Acceptance Criteria – 2: Update Quantity Given The Request is authenticated. When The Input contains the user login id, product id, and Quantity. Then The System ensures that the Quantity is greater than ZERO AND the System will update the Quantity in the cart DB. AND if there is an error in updating System will show "Unable to update the Quantity."
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.
Cycles Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search User Journey Search by Price Image Gallery Update Qty Use UPI R2 Global Search Product Details Add to Cart Delete Item Select Address Confirm Order Pay Credit Card Make Payment R1 Registration Minimum Viable Product Scrum Sprint Cycle Search by Price Image Gallery Update Qty Use UPI Kanban Cycle: Each of the Stories can be released without waiting for other stories to be completed resulting in Shorter Releases as all the stories are independent!
Solutions o Business Capabilities 2. Business Driven Teams (From Specs to Ops) 3. Outcome Oriented instead of Activity Oriented. 4. User Stories 1. Story Points 2. Velocity 5. Behavior Driven Design Business Solution Business Process 1 Business Process 2 Business Process n Business Functions 1 User Stories BDD Story Points MVP – User Journey Business Functions n Business Functions 1 Business Functions n Business Functions 1 Business Functions n Capabilities
AND TOOLS WORKING SOFTWARE COMPREHENSIVE DOCUMENTATION OVER CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION RESPONDING TO CHANGE OVER FOLLOWING A PLAN Source: Agile Manifesto - https://www.scrumalliance.org/resources/agile-manifesto Key in Microservices Architecture
Sprint Planning 4 – 8 People Max 8 Hours Max 15 Mins Multiple increments within a Sprint 1 Month Release Increment Stories Planned for a Sprint Sprint Backlog Product Backlog Complete Specs
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.
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
held at the start of Each Sprint. • Each Sprint must deliver working and fully tested code that demonstrate value to the customer. • Product Owner Prioritizes the Product Backlog. • Team Collectively selects the Amount of Work brought into Sprint • Once a sprint begins, only the team may add to the Sprint backlog. • A Short Scrum meeting is done every day. 91 Source: User Stories Applied by Mike Cohn. Page 204
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.
- 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.
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
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.
the flow of work 2. Limit WIP (Work in Progress) 3. Manage Flow 4. Make Process Policies Explicit 5. Implement Feedback Loops 6. Improve Collaboratively, Evolve Experimentally Source: https://www.digite.com/kanban/what-is-kanban/
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.
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/
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
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
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).
and by Value, data is transferred. o You can upgrade a layer without worrying about the impact on the other layer as long as the contract between the layers is intact. o The logic Tier can be further divided into 1. Web Services Layer 2. Business Layer 3. Database Layer Layered Architecture Style 106 UI Layer WS BL DL Database Shopping Cart Order Customer Product John J. Donovan developed it in Open Environment Corporation (OEC), a tools company he founded in Cambridge, Massachusetts. 3 Tier Architecture Pattern https://professordonovan.com/open-environment-corporation Presentation Tier UI is the topmost level of the Application. The primary function of the UI is to give a better Human-Machine Interaction. Logic Tier The Logic Tier is the intermediary between the Presentation and Database Tier. Its responsibilities include Interpreting commands, Making logical decisions and evaluations, Performing calculations, and Facilitating the movement and processing of data between the surrounding layers. Database Tier The information is stored and retrieved from the Database Tier. The data is sent back to the Logic Tier for processing and then back to Presentation Tier for the User to take action.
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.
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
style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. https://martinfowler.com/articles/microservices.html By James Lewis and Martin Fowler Bolo Definition Kya hai? Tell me what’s the definition
independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation via IaC Design for Failure Evolutionary Design Source: US DoD DevSecOps Fundamentals Playbook. Page 6
of architecture components: 1. a core system and 2. plug-in modules. Application logic is divided between 1. independent plug-in modules 2. and the basic core system, providing 3. extensibility, 4. flexibility, and 5. isolation of application features 6. and custom processing logic Micro Kernel Architecture Pattern 112 Source: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch03.html Plug-In Component Plug-In Component Plug-In Component Core System Plug-In Component Plug-In Component Plug-In Component
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
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
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
Customer Profile – Aggregate Root Profile Address Title Profile Created Profile Address New Title Title Updated Profile New Address New Title New Address added Derived Profile Address Notes Notes Removed Time T1 T2 T4 T3 Event Sourcing and Derived Aggregate Root Commands 1. Create Profile 2. Update Title 3. Add Address 4. Delete Notes 1 Events 1. Profile Created Event 2. Title Updated Event 3. Address Added Event 4. Notes Deleted Event 2 Profile Address New Title Current State of the Customer Profile 3 Event store Single Source of Truth Greg Young
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
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/ •
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
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
Used in all forms of spoken / written communication Ubiquitous Language Domain Expert Analyst Developers QA Design Docs Test Cases Code Restaurant Context – Food Item : Eg. Food Item (Navrathnakurma) can have different meaning or properties depends on the context. • In the Menu Context it’s a Veg Dish. • In the Kitchen Context it’s is recipe. • And in the Dining Context it will have more info related to user feed back etc. DDD: Ubiquitous Language: Strategic Design 127 As an Restaurant Owner I want to know who my Customers are So that I can serve them better Role-Feature-Reason Matrix BDD – Behavior Driven Development Given Customer John Doe exists When Customer orders food Then Assign customer preferences as Veg or Non Veg customer BDD Construct
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.
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?
App User’s Journey can run across multiple Bounded Context / Micro Services. Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Dinning Order Reservation Tables Recipes Raw Materials Frozen Semi Cooked Appetizer Veg Appetizer Non Veg Soft Drinks Main Course Non Veg Main Course Veg Hot Drinks Desserts Steward Chef Menu uses uses Understanding Bounded Context (DDD) of a Restaurant App Dinning Context Kitchen Context Menu Context Source: Domain-Driven Design Reference by Eric Evans Areas of the domain treated independently Discovered as you assess requirements and build language Bounded Context Bounded Context Bounded Context User Journey X
and Practices of DDD – Page 124 This model shows multiple responsibilities of the shared Model – Product. This is a classic example of Big Ball of Mud. 131
Martin Fowler : http://martinfowler.com/bliki/BoundedContext.html • DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships. • Bounded Contexts have both unrelated concepts • Such as a support ticket only existing in a customer support context • But also share concepts such as products and customers. • Different contexts may have completely different models of common concepts (Customer & Product) with mechanisms to map between these polysemic concepts for integration. 133
Customer • Customer ID • Discount • Bonus Program Delivery Customer • Customer ID • Address • Preferred Delivery method • Packaging • Delivery Contact Billing Customer • Customer ID • Billing Address • Payment Type • Tax o Customer Model has different attributes in different contexts. So it avoids storing all the customer info in one place and then sharing that across multiple Bounded Contexts (Microservices). o If you want to change Customer details related to Tax then only Billing Bounded Context (Microservice) needs to be updated.
and Practices of DDD – Page 132 Each of this Bounded Context will become a Microservice Communication across Bounded Context Source: Patterns, Principles and Practices of DDD – Page 203 135
the Adapter and the Domain is identified as the Ports layer. The Domain is inside the port, and adapters for external entities are outside the port. The notion of a “port” invokes the OS idea that any device that adheres to a known protocol can be plugged into a port. Similarly, many adapters may use the Ports. Source : http://alistair.cockburn.us/Hexagonal+architecture https://skillsmatter.com/skillscasts/5744-decoupling-from-asp-net-hexagonal-architectures-in-net Services for UI Ports File system Database Order Tracking JPA Repository Implementation Adapters OrderProcessing Domain Service (Business Rules) Implementation Domain Models Domain Layer Order Data Validation OrderService REST Service Implementation OrderProcessing Interface p Order Tracking Repository Interface p A A External Apps A A A Others A A OrderService Interface p Web Services Data Store Use Case Boundary Bounded Context A • Reduces Technical Debt • Dependency Injection • Auto Wiring 138
the Domain Explore models in collaboration of Domain Experts & Software Experts Write software that expresses these Models explicitly Speak Ubiquitous Language within a Bounded Context 141 Eric Evans – Explore DDD, Denver, 2017
is critical for the success of the business. Why are these areas important? Why can't we buy a solution rather than building it? What makes the system worth building it? Core Domain 143 Look at the Core Domain as a Product instead of a Project
the Core Domain. In an E-Commerce application like Amazon or Flipkart, product search functionality is a supporting domain. Even off the shelf application can be used in a supporting domain, For Ex. Ticketing system. Supporting Domains 144
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.
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
Capabilities from the User Activities / Stories / Use Cases Based on Activities: If an area within the system contains a set of exclusive activities then that’s an indicator for a Business Capabilities. Based on Trigger: Any area which gets automatically triggered based on external input and does some activities based on that trigger. Ex. Spam Checker, Virus Checker in mail attachments. 149
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
map provides Global View of the system that UML or architecture diagrams completely miss, helping us to focus on choices that are really viable in your scenario without wasting money. 2. Each Bounded Context fits within the Context Map to show how they should communicate amongst each other and how data should be shared. 154 Up Stream (u) – Down Stream (d) The upstream team may succeed independently of the fate of the downstream team. Mutually Dependent Success depends on the success of both the teams. Free In which success or failure of the development work in other contexts has little affect on delivery.
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.
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.
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
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
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
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
• 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
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
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
Invariants in Consistency Boundaries. This rule has the added implication that you should modify just one Aggregate instance in a single transaction. In other words, when you are designing an Aggregate composition, plan on that representing a transaction boundary. 2. Design Small Aggregates. The smallest Aggregate you can design is one with a single Entity, which will serve as the Aggregate Root. 3. Reference Other Aggregates Only By Identity. 4. Use Eventual Consistency Outside the Consistency Boundary. This means that ONLY ONE Aggregate instance will be required to be updated in a single transaction. All other Aggregate instances that must be updated as a result of any one Aggregate instance update can be updated within some time frame (using a Domain Event). The business should determine the allowable time delay. 5. Build Unidirectional Relationship from the Aggregate Root. 167
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
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
Observable 172 First Class Visitor (Consumer) Serial Operations Parallel Streams (10x Speed) Still On Next, On Complete and On Error are Serial Operations Completely Asynchronous Operations Java 8 – Blocking Call Java 6 – Blocking Call Rx Java - Freedom
/ FlatMap 173 Objective: toSortedList() returns an Observable with a single List containing Fruits. Using FlatMap to Transform Observable <List> to Observable <Fruit> Rx Example 2
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
• Data obtained from untrusted sources, such as user input from a Web page, should be cleansed and validated before being placed into a DTO. Doing so enables you to consider the data in the DTO relatively safe, which simplifies future interactions with the DTO. 175 The Problem Assembler Pattern An object that carries data between processes in order to reduce the number of method calls. Benefits 1. Reduced Number of Calls 2. Improved Performance 3. Hidden Internals 4. Discovery of Business objects Liabilities 1. Class Explosion 2. Additional Computation 3. Additional Coding Effort https://msdn.microsoft.com/en-us/library/ms978717.aspx Problem: How do you preserve the simple semantics of a procedure call interface without being subject to the latency issues inherent in remote communication? The Solution 401 P of EAA
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
pattern to achieve one or more of the following objectives: • You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing. • You access the data source from many locations and want to apply centrally managed, consistent access rules and logic. • You want to implement and centralize a caching strategy for the data source. • You want to improve the code's maintainability and readability by separating business logic from data or service access logic. • You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time. • You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity. • You want to apply a domain model to simplify complex business logic. 178 Repository Pattern Source: Martin Fowler : http://martinfowler.com/eaaCatalog/repository.html | Microsoft : https://msdn.microsoft.com/en-us/library/ff649690.aspx Mediates between the domain and data mapping layers using a collection- like interface for accessing domain objects. 322 P of EAA Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.
are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. • The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. • The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. • The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. 179 Source: Anemic Domain Model By Martin Fowler : http://martinfowler.com/bliki/AnemicDomainModel.html • lockUser() • unlockUser() • addAddress(String address) • removeAddress(String address)
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
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
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
183 Procedural Way Builder Pattern Source: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html Domain Driven Design with Java EE 6 By Adam Bien | Javaworld
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
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
• 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
@Repository Model @Entity Data Store Firewall Users DTO @Autowired Service … @Autowired Repository … Dependency Injection Form of IoC Dispatcher Servlet Handler Mapping /cart/customer/{customerId}
Request Listener HTTP Firewall Final Checks on the Response. Integrated into Filter Chain Proxy HTTP Firewall Security checks are performed. Ex. Protocols, Special Chars in URLs API Flow 193 Servlet Filter Chain Servlet Filters. Ex. Log Filter Security Filter Dispatcher Servlet Spring main Front controller Handler Mapping Route request to controller Interceptor Spring Context Pre Handlers Ex. JWT, Rate Limit AOP Before Advice JWT Controller Your Controller Business Service Servlet Filter Chain Servlet Filters. Ex. Add Response Headers Interceptor After Completion Ex. Response Time Calculation View Rendering Renders based on Model View Object Skipped for REST Calls Interceptor Spring Context Post Handlers Ex. Log Data AOP After Advice Controller Your Controller Business Service Servlet Context Spring Context App Context Message Conversion Response Entity Converted to JSON Request Initialized Request Destroyed 1 2 3 4 5 6 7 8
titled "Architectural Styles and the Design of Network-based Software Architectures. Chapter 5 REpresentational State Transfer 1. Client-Server Architecture REST is based on the separation of concerns between the client (the user interface and client-side logic) and the server (the data storage and server-side logic). This separation allows the client and server to evolve independently, improving the scalability and portability of the user interface across multiple platforms. 2. Statelessness Each request from the client to the server must contain all the information necessary to understand and complete the request. The server should not store any client context between requests. This statelessness ensures that each request can be treated independently, which increases reliability and scalability but may reduce efficiency in some cases where state information must be transferred with each request. 3. Cacheability Responses must, implicitly or explicitly, define themselves as cacheable or non-cacheable. If a response is cacheable, the client cache is given the right to reuse that response data for later, equivalent requests. Cacheability can reduce the need for some client-server interactions, improving efficiency, scalability, and user-perceived performance.
titled "Architectural Styles and the Design of Network-based Software Architectures. Chapter 5 REpresentational State Transfer 4. Layered System A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers can improve system scalability by enabling load balancing and shared caches. They can also enforce security policies. 5. Code on Demand (optional) Servers can temporarily extend or customize the functionality of a client by transferring executable code. Examples include compiled components, scripts, or applets. This is an optional constraint, and it enables clients to support new features by downloading code from the server, though it can compromise security.
titled "Architectural Styles and the Design of Network-based Software Architectures. Chapter 5 REpresentational State Transfer 6. Uniform Interface The uniform interface between clients and servers is a fundamental aspect that differentiates REST from other network architectures. This interface simplifies and decouples the architecture, allowing each part to evolve independently. The uniform interface is defined by four constraints: 1. Resource Identification in Requests: Individual resources are identified in requests, using URIs in Web- based REST systems. 2. Resource Manipulation through Representations: When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so. 3. Self-descriptive Messages: Each message includes enough information to describe how to process the message. 4. Hypermedia as the Engine of Application State (HATEOAS): Clients deliver state via body contents, query-string parameters, request headers, and the requested URI (the resource name). Services deliver state to clients via body content, response codes, and response headers. This is often simplified to the principle that clients interact with a network application entirely through hypermedia provided dynamically by application servers.
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
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
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
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.
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
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
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
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.
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
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
RabbitMQ 3. IBM: Apache Kafka – Sept 18, 2020 4. Confluent: Apache Kafka Fundamentals – April 25, 2020 5. Confluent: How Kafka Works – Aug 25, 2020 6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020 7. Kafka Streams – Sept 4, 2021 8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018 9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019
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?
IBM: Virtual Machines and Containers 2. IBM: What is a Hypervisor? 3. IBM: Docker Vs. Kubernetes 4. IBM: Containerization Explained 5. IBM: Kubernetes Explained 6. IBM: Kubernetes Ingress in 5 Minutes 7. Microsoft: How Service Mesh works in Kubernetes 8. IBM: Istio Service Mesh Explained 9. IBM: Kubernetes and OpenShift 10. IBM: Kubernetes Operators 11. 10 Consideration for Kubernetes Deployments Istio – Metrics 1. Istio – Metrics 2. Monitoring Istio Mesh with Grafana 3. Visualize your Istio Service Mesh 4. Security and Monitoring with Istio 5. Observing Services using Prometheus, Grafana, Kiali 6. Istio Cookbook: Kiali Recipe 7. Kubernetes: Open Telemetry 8. Open Telemetry 9. How Prometheus works 10. IBM: Observability vs. Monitoring
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
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
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
“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
otsuki
hiyokose
chaspy
shintanimoto
kakehashi
shumpei3
bgpat
tomzoh
potix2
meihei3
tadayukinakamura
os1ma
rocio
chrisshort
palkan
keathley
aarron
eitanlees
sferik
reverentgeek
smashingmag
tammyeverts
mojombo
mraible
