System Context Diagram
แผนผังบริบทของระบบ
แสดงผู้ใช้งานทั้งหมด (Employee, Manager, HR Admin, Super Admin, Executive) และการเชื่อมต่อกับระบบภายนอก เช่น ZKBio IoMatrix สำหรับบันทึกเวลาเข้าออก LINE Official Account สำหรับการแจ้งเตือน และ Bank API สำหรับการโอนเงินเดือน
graph TB subgraph Users["👥 Users | ผู้ใช้งาน"] E["👤 Employee
พนักงาน"] M["👔 Manager
หัวหน้า"] HR["💼 HR Admin
ฝ่ายบุคคล"] SA["🔧 Super Admin
IT"] EX["🎩 Executive
ผู้บริหาร"] end HRIS["🏢 ZPOT HRIS
System"] E --> HRIS M --> HRIS HR --> HRIS SA --> HRIS EX --> HRIS HRIS --> ZK["🔐 ZKBio IoMatrix
Face Scan
Attendance Device"] HRIS --> LINE["💬 LINE Official Account
Notification Service"] HRIS --> BANK["🏦 Bank API
Payroll Transfer"] HRIS --> LOGTO["🔑 Logto
Authentication"] style HRIS fill:#3b82f6,stroke:#1e40af,color:#fff style Users fill:#dbeafe,stroke:#0284c7 style ZK fill:#fecaca,stroke:#dc2626 style LINE fill:#99f6e4,stroke:#0d9488 style BANK fill:#fcd34d,stroke:#ca8a04 style LOGTO fill:#d8b4fe,stroke:#7c3aed
🔍 Key Design Points | จุดออกแบบหลัก
  • 5 User Roles: แบ่งสิทธิ์การเข้าถึงตามบทบาท (RBAC Model)
  • External Integrations: ระบบภายนอก 4 อย่างหลัก สำหรับ Attendance, Notification, Payment
  • Single Source of Truth: ฐานข้อมูลส่วนกลาง (PostgreSQL) สำหรับข้อมูลทั้งหมด
  • Scalable Design: สามารถเพิ่มจำนวนผู้ใช้งานได้โดยไม่กระทบระบบ
Infrastructure Architecture
สถาปัตยกรรมโครงสร้างพื้นฐาน
แสดงโครงสร้างแบบ containerized ที่ใช้ Cloudflare Edge สำหรับ CDN และ WAF, Cloudflare Workers สำหรับ Rate Limiting, Digital Ocean VPC สำหรับ Backend, Database, Cache, Async Workers, Storage, และ Observability Stack
graph TB subgraph CF["☁️ Cloudflare Edge
- DNS, WAF, CDN"] DNS["DNS Management"] WAF["WAF Protection"] CDN["Static Assets Cache"] SSL["SSL/TLS Encryption"] end subgraph CFW["☁️ Cloudflare Workers
- Edge Computing"] RateLimit["Rate Limiter"] Validation["Request Validation"] end subgraph Pages["📱 Frontend"] SPA["Nuxt.js SPA
Vue Components
PWA"] end subgraph Backend["🖥️ Backend Servers
zoo-backend (4vCPU, 8GB)"] Nginx["Nginx
Load Balancer"] API1["FastAPI Replica 1"] API2["FastAPI Replica 2"] API3["FastAPI Replica 3"] end subgraph Database["🗄️ Database
zoo-database (2vCPU, 4GB)"] PgBouncer["PgBouncer"] PostgreSQL["PostgreSQL 15"] end subgraph Cache["⚡ Redis 7"] CacheLayer["Distributed Cache"] QueueLayer["Task Queue"] end subgraph Workers["🔄 Celery Workers"] PayrollWorker["Payroll Calculator"] ReportWorker["Report Generator"] NotifWorker["Notification Sender"] end subgraph Storage["☁️ DO Spaces S3"] Docs["Documents"] Exports["Exports"] Backups["Backups"] end subgraph Observability["📊 Monitoring Stack"] Grafana["Grafana"] Loki["Loki Logs"] Mimir["Metrics"] end CF -->|HTTPS| CFW CFW -->|Forward| Pages CFW -->|Forward| Nginx Pages -->|API Calls| Nginx Nginx -->|LB| API1 Nginx -->|LB| API2 Nginx -->|LB| API3 API1 --> PgBouncer API2 --> PgBouncer API3 --> PgBouncer PgBouncer --> PostgreSQL API1 --> Cache API2 --> Cache API3 --> Cache Cache --> Workers Workers --> Storage API1 --> Observability API2 --> Observability API3 --> Observability style CF fill:#3b82f6,color:#fff style CFW fill:#06b6d4,color:#fff style Backend fill:#8b5cf6,color:#fff style Database fill:#ec4899,color:#fff style Cache fill:#f59e0b,color:#fff style Workers fill:#10b981,color:#fff
💡 Infrastructure Details | รายละเอียดโครงสร้าง
  • Edge Layer: Cloudflare ให้ CDN, WAF, DDoS Protection, DNS Management
  • Backend: 3 replicas FastAPI พร้อม Nginx Load Balancer
  • Database: PostgreSQL 15 แบบ Primary-Replica สำหรับ Read Scaling
  • Cache: Redis สำหรับ Session, Cache, Task Queue
  • Async Processing: Celery Workers สำหรับ Heavy Tasks (Payroll, Reports)
  • Monitoring: Grafana + Loki + Mimir สำหรับ Complete Observability
Module Dependency Diagram
แผนผังการอ้างอิงระหว่างโมดูล
แสดงความสัมพันธ์ระหว่างโมดูลธุรกิจต่างๆ โดย Authentication เป็นโมดูลพื้นฐานที่ไม่ขึ้นอยู่กับใคร, Payroll ขึ้นอยู่กับโมดูลอื่น ๆ มากมาย (Employee, Attendance, Leave, Benefits), Notification และ Workflow เป็นโมดูล Cross-cutting ที่เชื่อมต่อหลายโมดูล
graph TD AUTH["🔐 auth
Authentication
Authorization
(Foundation)"] ORG["🏢 org
Organization
Structure"] ORG -->|depends| AUTH EMP["👤 employee
Employee
Management"] EMP -->|depends| AUTH EMP -->|depends| ORG ATT["📍 attendance
Attendance &
Presence"] ATT -->|depends| AUTH ATT -->|depends| EMP LEA["📅 leave
Leave & Time Off"] LEA -->|depends| AUTH LEA -->|depends| EMP LEA -->|depends| ORG BEN["💳 benefits
Benefits &
Allowances"] BEN -->|depends| AUTH BEN -->|depends| EMP BEN -->|depends| ORG PAY["💰 payroll
Payroll &
Compensation"] PAY -->|depends| AUTH PAY -->|depends| EMP PAY -->|depends| ATT PAY -->|depends| LEA PAY -->|depends| BEN PERF["⭐ performance
Performance
Management"] PERF -->|depends| AUTH PERF -->|depends| EMP PERF -->|depends| ORG TAL["🎯 talent
Talent
Management"] TAL -->|depends| AUTH TAL -->|depends| EMP TAL -->|depends| PERF LEARN["📚 learning
Learning &
Development"] LEARN -->|depends| AUTH LEARN -->|depends| EMP LEARN -->|depends| TAL KNOW["📖 knowledge
Knowledge Base"] KNOW -->|depends| AUTH KNOW -->|depends| ORG NOTIF["🔔 notification
(Cross-cutting)"] NOTIF -->|depends| AUTH NOTIF -.->|notifies| EMP NOTIF -.->|notifies| LEA NOTIF -.->|notifies| PAY NOTIF -.->|notifies| PERF REPORT["📊 report
(Read-only)
Reporting"] REPORT -->|reads| AUTH REPORT -->|reads| EMP REPORT -->|reads| ATT REPORT -->|reads| LEA REPORT -->|reads| PAY WF["⚙️ workflow
(Cross-cutting)
Workflow Engine"] WF -->|depends| AUTH WF -->|depends| ORG WF -.->|orchestrates| LEA WF -.->|orchestrates| PAY WF -.->|orchestrates| PERF style AUTH fill:#ff9999,color:#000 style NOTIF fill:#ffcc99,color:#000 style REPORT fill:#99ccff,color:#000 style WF fill:#99ff99,color:#000 style PAY fill:#ff99cc,color:#000
🎯 Design Principles | หลักการออกแบบ
  • Layered Dependencies: โมดูลพื้นฐาน (auth) ไม่ขึ้นอยู่กับใคร
  • Core Modules: org, employee เป็นโมดูลหลักที่เป็น dependency ของหลายโมดูล
  • Heavy Consumer: payroll ขึ้นอยู่กับ 5 โมดูลอื่น (attendance, leave, benefits, employee, auth)
  • Cross-cutting Concerns: notification และ workflow เชื่อมต่อหลายโมดูลโดยไม่ถูกขึ้นอยู่
  • Read-only Reporting: report module อ่านจากทุกโมดูลแต่ไม่เขียน
  • Microservices Path: สามารถแยกเป็น microservice ตามลำดับการพึ่งพา
Deployment Architecture
สถาปัตยกรรมการปรับใช้งาน
แสดงการจัดเตรียมฮาร์ดแวร์และเครือข่ายในสภาพแวดล้อม production ที่ใช้ Digital Ocean VPC, Cloudflare Edge, และมี Load Balancer สำหรับ High Availability และ Failover
graph TB subgraph Global["🌍 Global"] CF_EDGE["☁️ Cloudflare Edge
Singapore
DNS, WAF, CDN"] end subgraph DO_SG["🏢 Digital Ocean - Singapore Region"] subgraph VPC["🔐 Private VPC
172.16.0.0/12"] subgraph BACKEND_NET["Backend Network"] BE_LB["🔀 Load Balancer
Floating IP
165.232.xxx.xxx"] BE_D1["zoo-backend-1
4 vCPU, 8GB RAM
$48/month
Primary"] BE_D2["zoo-backend-2
4 vCPU, 8GB RAM
$48/month
Standby"] end subgraph DB_NET["Database Network"] DB_LB["🔀 DB Failover
Private IP
172.16.1.10"] DB_PRIMARY["zoo-database
2 vCPU, 4GB RAM
$28/month
PostgreSQL 15"] DB_REPLICA["zoo-database-replica
2 vCPU, 4GB RAM
$28/month
Read Replica"] end subgraph CACHE_NET["Cache Network"] REDIS["Redis 7
Managed
1GB Memory
$12/month"] end subgraph OBS_NET["Observability Network"] OBS["zoo-observability
2 vCPU, 4GB RAM
$28/month
Grafana, Loki, Mimir"] end end subgraph STORAGE["☁️ Storage"] S3["DO Spaces S3
Object Storage
$5/month"] end end CF_EDGE -->|HTTPS/443| BE_LB BE_LB -->|LB| BE_D1 BE_LB -->|LB| BE_D2 BE_D1 -->|Private| DB_LB BE_D2 -->|Private| DB_LB DB_LB -->|Primary| DB_PRIMARY DB_LB -->|Replica| DB_REPLICA BE_D1 -->|Cache| REDIS BE_D2 -->|Cache| REDIS BE_D1 -->|Logs| OBS BE_D2 -->|Logs| OBS BE_D1 -->|Store| S3 BE_D2 -->|Store| S3 style CF_EDGE fill:#3b82f6,color:#fff style VPC fill:#f3f4f6,stroke:#9ca3af,stroke-width:2px style STORAGE fill:#f3f4f6,stroke:#9ca3af,stroke-width:2px
💰 Cost Breakdown | ราคา/เดือน
  • Backend Servers: $48 × 2 = $96/month (Redundancy)
  • Database: $28 × 2 = $56/month (Primary + Replica)
  • Redis Cache: $12/month
  • Observability: $28/month
  • Storage: $5/month (DO Spaces)
  • Cloudflare: ~$20/month (Pro Plan)
  • Total: ~$217/month
  • HA Strategy: Load Balancer + Floating IP สำหรับ Automatic Failover
CI/CD Pipeline
ท่อ Continuous Integration & Continuous Deployment
แสดงกระบวนการอัตโนมัติจาก GitHub Webhook ผ่าน Linting, Unit Tests, Integration Tests, Build Docker Image, Push to Registry, Deploy to Staging, และ Production โดยมี Health Checks และ Automatic Rollback
graph LR subgraph Source["📝 Source Control"] REPO["GitHub Repository
zoo-hris"] end subgraph Trigger["🎯 Trigger"] PUSH["Push to main
or PR to main"] end subgraph Testing["✅ Testing Phase"] LINT["Linting
Black, Ruff
Pylint"] UNIT["Unit Tests
pytest
95% coverage"] INTEG["Integration Tests
Test DB, Redis"] BUILD["Build Docker
Image"] end subgraph Registry["📦 Container Registry"] REGISTRY["DO Container Registry
zoo-hris/backend:vX.X.X"] end subgraph Deployment["🚀 Deployment"] STAGING["Deploy Staging
zoo-backend-staging
Smoke Tests"] PROD["Deploy Production
Blue-Green
Gradual Rollout"] end subgraph Monitor["📊 Monitoring"] CHECK["Health Checks
Error Rate, Performance"] ROLLBACK["Auto Rollback
on Failure"] end REPO -->|Event| Trigger Trigger -->|Webhook| LINT LINT -->|✓| UNIT UNIT -->|✓| INTEG INTEG -->|✓| BUILD BUILD -->|Push| REGISTRY REGISTRY -->|Deploy| STAGING STAGING -->|Manual| PROD PROD -->|Continuous| CHECK CHECK -->|Failure| ROLLBACK CHECK -->|Success| SUCCESS["✅ Live"] ROLLBACK -->|Revert| REGISTRY style LINT fill:#86efac,color:#000 style UNIT fill:#86efac,color:#000 style INTEG fill:#86efac,color:#000 style BUILD fill:#86efac,color:#000 style SUCCESS fill:#86efac,color:#000 style ROLLBACK fill:#fca5a5,color:#000
🔧 Pipeline Configuration | การตั้งค่าท่อ
  • Trigger: Push to main branch หรือ PR to main
  • Code Quality: Black (Format), Ruff (Lint), Pylint (Style)
  • Testing: Unit Tests 95% coverage + Integration Tests
  • Build: Docker Image Build กับ Multi-stage optimization
  • Deployment Strategy: Blue-Green เพื่อ Zero-downtime
  • Validation: Smoke Tests + Health Checks + Error Rate Monitor
  • Rollback: Automatic rollback หากเกิด Error
Leave Request Sequence Diagram
แผนผังลำดับขั้นการขอลา
แสดงลำดับการทำงานเมื่อพนักงานขอลา โดยระบบตรวจสอบ Leave Balance, สร้าง Leave Request, ส่งการแจ้งเตือนให้หัวหน้า, หัวหน้าอนุมัติ, อัปเดต Database, และส่งการแจ้งเตือนให้พนักงาน
sequenceDiagram participant EMP as Employee
พนักงาน participant HRIS as HRIS System participant NOTIF as Notification
Service participant MGR as Manager
หัวหน้า participant DB as Database EMP->>HRIS: 1. Submit Leave Request
(Dates, Reason, Type) activate HRIS HRIS->>DB: 2. Validate Leave Balance DB-->>HRIS: ✓ Balance Available HRIS->>DB: 3. Create Request
(Status: PENDING) DB-->>HRIS: Request ID: LR-2024-001 HRIS->>NOTIF: 4. Notify Manager
(LINE, Email) activate NOTIF NOTIF-->>MGR: New Leave Request
for Approval deactivate NOTIF MGR->>HRIS: 5. Review & Approve activate HRIS HRIS->>DB: 6. Update Status
(Status: APPROVED) DB-->>HRIS: Updated HRIS->>DB: 7. Deduct Balance
(Balance - Days) DB-->>HRIS: New Balance: 15 days HRIS->>DB: 8. Update Calendar
(Mark dates as OFF) DB-->>HRIS: Calendar Updated HRIS->>NOTIF: 9. Notify Employee
(Approval + New Balance) activate NOTIF NOTIF-->>EMP: Leave Approved✓
New Balance: 15 days deactivate NOTIF deactivate HRIS EMP->>HRIS: 10. View Updated Balance
& Calendar
📋 Leave Request Process | ขั้นตอนการขอลา
  • Validation: ตรวจสอบ Leave Balance ว่ามีวันลาเพียงพอหรือไม่
  • Request Creation: สร้าง Leave Request Record ในสถานะ PENDING
  • Manager Notification: ส่งการแจ้งเตือนให้หัวหน้า ผ่าน LINE และ Email
  • Approval Workflow: หัวหน้าทำการอนุมัติหรือปฏิเสธ
  • Balance Update: อัปเดตวันลาคงเหลือ
  • Calendar Sync: อัปเดต Attendance Calendar ให้ Mark วันลา
  • Employee Notification: ส่งผลลัพธ์การอนุมัติให้พนักงาน
Authentication Flow
แผนผังกระบวนการตรวจสอบสิทธิ์
แสดงกระบวนการ Login โดยใช้ Logto Authentication Server เป็นตัวจัดการการตรวจสอบสิทธิ์, สร้าง JWT Token, ทำการ Code Exchange สำหรับ OAuth Flow, และจัดเก็บ Secure Cookie
sequenceDiagram participant USER as User
Browser participant PAGES as Frontend
Cloudflare Pages participant LOGTO as Logto Auth
Server participant API as HRIS API
Backend participant DB as Database USER->>PAGES: 1. Visit www.zoo-hris.com PAGES-->>USER: 2. Load Login Page USER->>PAGES: 3. Click Login Button PAGES->>LOGTO: 4. Redirect to Logto
(client_id, redirect_uri) LOGTO-->>USER: 5. Login Form USER->>LOGTO: 6. Enter Credentials
(Email, Password) LOGTO->>DB: 7. Validate Credentials DB-->>LOGTO: ✓ User Valid LOGTO->>LOGTO: 8. Generate JWT Token
(HS256, 1 hour expiry) LOGTO-->>USER: 9. Redirect to HRIS
with Authorization Code USER->>PAGES: 10. Request with Code PAGES->>API: 11. Exchange Code for Token
(server-side) API->>LOGTO: 12. Token Exchange LOGTO-->>API: 13. Return JWT API->>DB: 14. Verify User Role
& Permissions DB-->>API: 15. Return Role Data API-->>PAGES: 16. Set Secure Cookie
(httpOnly, secure, sameSite) PAGES-->>USER: 17. Redirect to Dashboard USER->>PAGES: 18. Load Dashboard PAGES->>API: 19. API Call with JWT API->>API: 20. Validate JWT Signature API-->>PAGES: 21. ✓ Authorized Response PAGES-->>USER: 22. Render Dashboard
🔐 Authentication Details | รายละเอียดการตรวจสอบสิทธิ์
  • Provider: Logto (OpenID Connect)
  • Token Type: JWT (JSON Web Token)
  • Signing Algorithm: HS256 (HMAC with SHA-256)
  • Token Expiry: 1 hour (short-lived access)
  • Refresh Token: 7 days (long-lived)
  • Storage: Secure HTTP-only cookie ป้องกัน XSS
  • CSRF Protection: SameSite=Strict
  • MFA: Optional, configurable per user
Payroll Data Flow
แผนผังการไหลของข้อมูลเงินเดือน
แสดงลำดับการไหลของข้อมูลตั้งแต่การบันทึก Attendance, Leave, Benefits, Tax Configuration เข้ามาในระบบ Payroll Calculation, สร้าง Payslip, และส่งเงินเดือนไปยังธนาคาร
graph TD ATT["📍 Attendance Data
Check-in/out Records"] LEA["📅 Leave Data
Approved Leave Days"] BEN["💳 Benefits Data
Enrollments, Deductions"] TAX["💼 Tax Configuration
Tax Rates, Rules"] OVERTIME["⏰ Overtime Data
Extra Hours"] CALC["🖥️ Payroll Calculation
Engine"] ATT --> CALC LEA --> CALC BEN --> CALC TAX --> CALC OVERTIME --> CALC CALC --> SALARY["💰 Salary Components
Base, Allowances"] CALC --> DEDUCT["📝 Deductions
Taxes, Benefits"] CALC --> NET["💵 Net Salary
Amount"] SALARY --> SLIP["📄 Payslip
Generation"] DEDUCT --> SLIP NET --> SLIP SLIP --> NOTIF["🔔 Notification
Send to Employee"] SLIP --> BANK["🏦 Bank Transfer
Payment Processing"] SLIP --> ARCHIVE["🗄️ Archival
Compliance Storage"] NOTIF -.->|LINE, Email| EMP["Employee"] BANK -.->|Transfer| BANKSVR["Bank Server"] ARCHIVE -.->|Store| STORAGE["Storage"] style CALC fill:#8b5cf6,color:#fff style SLIP fill:#3b82f6,color:#fff style ATT fill:#f59e0b,color:#fff style LEA fill:#f59e0b,color:#fff style BEN fill:#f59e0b,color:#fff
💰 Payroll Process | ขั้นตอนการคำนวณเงินเดือน
  • Data Collection: รวบรวมข้อมูล Attendance, Leave, Benefits, Tax จาก Modules ต่าง ๆ
  • Validation: ตรวจสอบความถูกต้องของข้อมูลก่อนการคำนวณ
  • Calculation: คำนวณ Salary Components (Base, Allowances, Bonuses)
  • Deductions: คำนวณ Taxes, Benefits, Social Security
  • Net Salary: คำนวณ Net Amount ที่จะจ่าย
  • Payslip Generation: สร้าง PDF Payslip สำหรับแต่ละพนักงาน
  • Distribution: ส่งเงินไปยังธนาคารและส่งการแจ้งเตือนให้พนักงาน
  • Archival: เก็บบันทึกเพื่อ Compliance (7+ years)
Database Schema Overview
แผนผังความสัมพันธ์ของข้อมูล
แสดงตารางหลักและความสัมพันธ์ระหว่างกัน เช่น Employee มีความสัมพันธ์กับ Department, Position, Attendance, Leave, Payslip, Benefits, Appraisal, Performance Goals เป็นต้น
erDiagram EMPLOYEE ||--o{ DEPARTMENT : "belongs_to" EMPLOYEE ||--o{ POSITION : "has" EMPLOYEE ||--o{ EMPLOYEE : "reports_to" EMPLOYEE ||--o{ ATTENDANCE_RECORD : "has" EMPLOYEE ||--o{ LEAVE_REQUEST : "creates" EMPLOYEE ||--o{ LEAVE_BALANCE : "has" EMPLOYEE ||--o{ PAYSLIP : "receives" EMPLOYEE ||--o{ BENEFIT_ENROLLMENT : "enrolls" EMPLOYEE ||--o{ APPRAISAL : "has" EMPLOYEE ||--o{ PERFORMANCE_GOAL : "has" LEAVE_REQUEST ||--o{ LEAVE_APPROVAL : "requires" LEAVE_BALANCE ||--o{ LEAVE_REQUEST : "tracks" PAYSLIP ||--o{ SALARY_COMPONENT : "includes" PAYSLIP ||--o{ DEDUCTION : "deducts" BENEFIT ||--o{ BENEFIT_ENROLLMENT : "enrolls" BENEFIT ||--o{ BENEFIT_COST : "has" DEPARTMENT ||--o{ TEAM : "contains" TEAM ||--o{ EMPLOYEE : "has_members" APPRAISAL ||--o{ APPRAISAL_RESULT : "produces" APPRAISAL ||--o{ APPRAISAL_COMMENT : "has"
🗄️ Database Structure | โครงสร้างฐานข้อมูล
  • Employee-centric: Employee เป็นตารางหลักที่เชื่อมต่อตารางอื่น ๆ
  • Organizational Structure: Department, Team, Position จัดระเบียบโครงสร้างองค์กร
  • Attendance Tracking: AttendanceRecord บันทึกเวลาเข้าออก
  • Leave Management: LeaveRequest, LeaveBalance, LeaveApproval จัดการวันลา
  • Compensation: Payslip, SalaryComponent, Deduction จัดการเงินเดือน
  • Benefits: Benefit, BenefitEnrollment, BenefitCost จัดการสวัสดิการ
  • Performance: Appraisal, AppraisalResult, Goal จัดการประเมินผล
  • Normalization: 3NF (Third Normal Form) เพื่อ Data Integrity
Event Bus Architecture
สถาปัตยกรรมระบบเหตุการณ์
แสดงวิธีการสื่อสารระหว่างโมดูลต่าง ๆ โดยใช้ Event Bus Pattern โดยปัจจุบันใช้ In-Memory Event Bus แบบ Synchronous และในอนาคตจะขยายไปใช้ Redis PubSub / RabbitMQ สำหรับ Asynchronous Communication
graph TB subgraph CurrentArch["🏗️ Current: Monolith
In-Memory EventBus"] direction TB subgraph Modules["📦 Business Modules"] AUTHM["auth module"] ORGM["org module"] EMPM["employee module"] ATTM["attendance module"] LEAM["leave module"] PAYM["payroll module"] end subgraph EventBus["🚌 In-Memory Event Bus"] PUBLISHER["Event Publisher
register_listener()
publish_event()"] DISPATCHER["Event Dispatcher
Direct Function Calls"] LISTENERS["Event Listeners
Synchronous"] end end subgraph FutureArch["🔮 Future: Microservices
Redis PubSub"] direction TB subgraph MS_Modules["📦 Microservices"] MS_AUTH["auth-service"] MS_ORG["org-service"] MS_EMP["employee-service"] MS_ATT["attendance-service"] MS_LEA["leave-service"] MS_PAY["payroll-service"] end subgraph MessageBroker["🚌 Redis PubSub"] REDIS_PUB["Publisher
PUBLISH channel"] REDIS_BROKER["Message Broker
Async Queue"] REDIS_SUB["Subscribers
SUBSCRIBE"] end subgraph DeadLetter["💀 Dead Letter Queue"] DLQ["Failed Events
Retry 3x
Exponential backoff"] end end %% Current Architecture AUTHM -->|publishes| PUBLISHER ORGM -->|publishes| PUBLISHER EMPM -->|publishes| PUBLISHER ATTM -->|publishes| PUBLISHER LEAM -->|publishes| PUBLISHER PAYM -->|publishes| PUBLISHER PUBLISHER -->|dispatch| DISPATCHER DISPATCHER -->|direct call| LISTENERS LISTENERS -->|listen| AUTHM LISTENERS -->|listen| ORGM LISTENERS -->|listen| EMPM LISTENERS -->|listen| ATTM LISTENERS -->|listen| LEAM LISTENERS -->|listen| PAYM %% Future Architecture MS_AUTH -->|publishes| REDIS_PUB MS_ORG -->|publishes| REDIS_PUB MS_EMP -->|publishes| REDIS_PUB MS_ATT -->|publishes| REDIS_PUB MS_LEA -->|publishes| REDIS_PUB MS_PAY -->|publishes| REDIS_PUB REDIS_PUB -->|async| REDIS_BROKER REDIS_BROKER -->|distribute| REDIS_SUB REDIS_SUB -->|subscribe| MS_AUTH REDIS_SUB -->|subscribe| MS_ORG REDIS_SUB -->|subscribe| MS_EMP REDIS_SUB -->|subscribe| MS_ATT REDIS_SUB -->|subscribe| MS_LEA REDIS_SUB -->|subscribe| MS_PAY REDIS_BROKER -->|failed| DLQ DLQ -->|retry| REDIS_BROKER style CurrentArch fill:#dbeafe,stroke:#0284c7,stroke-width:2px style FutureArch fill:#fed7aa,stroke:#ea580c,stroke-width:2px
🚌 Event Bus Pattern | รูปแบบ Event Bus
  • Current (Phase 1): In-Memory Event Bus ด้วย Synchronous Function Calls
  • Future (Phase 2): Redis PubSub สำหรับ Asynchronous Message Distribution
  • Event Examples: EmployeeCreated, LeaveApproved, PayrollCalculated, AppraisalCompleted
  • Subscribers: Each module registers listeners สำหรับ Events ที่เกี่ยวข้อง
  • Dead Letter Queue: Failed messages ถูก Retry 3 ครั้ง ด้วย Exponential Backoff
  • Microservices Path: การออกแบบนี้สำหรับการแยกเป็น Microservices ในอนาคต