Commit b5b2e4
2026-04-09 07:50:00 Melisha Dsouza: LLD| /dev/null .. CMMI/Templates/LLD.md | |
| @@ 0,0 1,132 @@ | |
| + | # **Low-Level Design (LLD) Template** |
| + | |
| + | ### **1. Problem Statement** |
| + | |
| + | - Clearly describe the problem in 2–3 lines |
| + | - Mention what needs to be achieved and why |
| + | |
| + | **Example:** |
| + | |
| + | Admin dashboard should display the count of pending transfers so that operations team can monitor incomplete transactions and take timely action. |
| + | |
| + | ### **2. Scope** |
| + | - What is included |
| + | - What is excluded (if any) |
| + | |
| + | ### **3. Solution Approach (Technical Design)** |
| + | #### **3.1 Overview** |
| + | - High-level explanation of the solution |
| + | - **Mention whether:** |
| + | - Existing services will be reused |
| + | - New services/APIs will be created |
| + | - Existing services will be enhanced |
| + | |
| + | #### **3.2 Components / Modules Involved** |
| + | - **List all impacted modules:** |
| + | - Backend services |
| + | - Frontend/UI |
| + | - Database |
| + | - External integrations (if any) |
| + | |
| + | #### **3.3 API Design** |
| + | - **For each API:** |
| + | - **API Name:** |
| + | - **Method**: (GET/POST/PUT/DELETE) |
| + | - **Endpoint:** |
| + | - **Request**: |
| + | - **Response**: |
| + | - **Auth Required:** Yes/No |
| + | - **Service Handling It:** |
| + | |
| + | #### **3.4 Data Flow** |
| + | - Step-by-step flow of how data moves across systems |
| + | - **Mention**: |
| + | - Source of data |
| + | - Processing logic |
| + | - Final output |
| + | |
| + | #### **3.5 Database Impact** |
| + | - New tables (if any) |
| + | - Changes in existing tables |
| + | - New fields/columns |
| + | - Indexing (if needed) |
| + | - Query changes |
| + | |
| + | #### **3.6 Business Logic** |
| + | - Core logic/conditions |
| + | - Rules to calculate/derive values |
| + | |
| + | **Example:** |
| + | |
| + | Pending transfer = transactions where status IN (initiated, processing, on-hold) |
| + | |
| + | #### **3.7 Service Design** |
| + | - Number of services impacted/added |
| + | - **Description of each:** |
| + | - New service |
| + | - Modified service |
| + | - Reusable service |
| + | |
| + | #### **3.8 Error Handling** |
| + | - Failure scenarios |
| + | - Retry mechanisms |
| + | - Logging strategy |
| + | - User-facing error messages |
| + | |
| + | #### **3.9 Edge Cases** |
| + | - List all possible edge cases |
| + | **Example:** |
| + | - Transfer stuck due to insufficient liquidity |
| + | - Partial transaction completion |
| + | - Duplicate requests |
| + | |
| + | #### **3.10 Performance Considerations** |
| + | - Query optimization |
| + | - Caching (if required) |
| + | - Pagination / batching |
| + | - Expected load |
| + | |
| + | #### **3.11 Security Considerations** |
| + | - Authentication / Authorization |
| + | - Data masking (if applicable) |
| + | - Sensitive data handling |
| + | |
| + | ### **4. Sequence Diagram** |
| + | - Visual flow of request → processing → response |
| + | - Must include: |
| + | - UI |
| + | - Backend service(s) |
| + | - DB |
| + | - External systems (if any) |
| + | |
| + | ### **5. Unit Test Criteria** |
| + | - Define test scenarios: |
| + | **Example:** |
| + | - Valid pending transfers count |
| + | - No data scenario |
| + | - Error response handling |
| + | - Edge case validation |
| + | |
| + | ### **6. Integration / QA Test Scenarios** |
| + | - End-to-end scenarios |
| + | - APIUI validation |
| + | |
| + | ### **7. Dependencies** |
| + | - External services |
| + | - Other modules |
| + | - Data availability |
| + | |
| + | ### **8. Assumptions** |
| + | - Any assumptions made during design |
| + | |
| + | ### **9. Risks & Mitigation** |
| + | - Potential risks |
| + | - How to handle them |
| + | |
| + | ### **10. Deployment / Rollout Plan** |
| + | - Any migration required |
| + | - Backward compatibility |
| + | - Feature flag (if needed) |
| + | |
| + | ### **11. Open Questions** |
| + | - Any pending clarifications |