TLX Software Architecture

เอกสารนี้ให้ภาพสถาปัตยกรรมระดับระบบเพื่อใช้เป็น baseline ในการออกแบบและตีราคาโครงการ

1) Architecture Goals

• รองรับธุรกรรมเอกสารการค้า/โลจิสติกส์แบบเชื่อถือได้และตรวจสอบย้อนหลังได้
• รองรับทั้ง Web Portal และ API Integration กับ ERP
• รองรับการตรวจสอบความถูกต้องข้อมูลทั้งเชิงโครงสร้างและความหมาย
• รองรับ security by design: authentication, authorization, key management, auditability

2) Logical Component Architecture

flowchart LR
    subgraph channels [Channels]
        webPortal["Web Portal"]
        backOffice["Back-office Portal"]
        externalERP["External ERP Systems"]
    end

    subgraph edge [Edge Layer]
        apiGateway["Secured API Gateway"]
        authService["AuthN/AuthZ Service"]
    end

    subgraph core [Core Business Layer]
        participantSvc["Participant Registry Service"]
        documentRegistrySvc["Document Registry Service"]
        productRegistrySvc["Product Catalog Registry Service"]
        orderSvc["Order Management Service"]
        deliverySvc["Delivery Management Service"]
        billingSvc["Invoice & Billing Service"]
        orchestrationSvc["Data Orchestration Service"]
        validationSvc["Message Validation Service"]
        notificationSvc["Notification Service"]
        trustSvc["Trust Service (Audit/Event)"]
        monitorSvc["Transaction Monitoring Service"]
        configSvc["Schema & Code List Config Service"]
    end

    subgraph data [Data Layer]
        appDb["Transactional Database"]
        auditStore["Audit/Event Store"]
        searchIndex["Search Index (Products/Participants)"]
        objectStore["Attachment/Object Storage"]
    end

    webPortal --> apiGateway
    backOffice --> apiGateway
    externalERP --> apiGateway
    apiGateway --> authService
    apiGateway --> orchestrationSvc
    apiGateway --> orderSvc
    apiGateway --> deliverySvc
    apiGateway --> billingSvc
    apiGateway --> participantSvc
    apiGateway --> productRegistrySvc

    orchestrationSvc --> validationSvc
    orchestrationSvc --> documentRegistrySvc
    orchestrationSvc --> participantSvc
    orchestrationSvc --> notificationSvc
    orchestrationSvc --> trustSvc

    orderSvc --> appDb
    deliverySvc --> appDb
    billingSvc --> appDb
    participantSvc --> appDb
    documentRegistrySvc --> appDb
    productRegistrySvc --> appDb
    monitorSvc --> appDb
    configSvc --> appDb

    trustSvc --> auditStore
    productRegistrySvc --> searchIndex
    participantSvc --> searchIndex
    apiGateway --> objectStore

3) End-to-End Message Processing Flow

sequenceDiagram
    participant SenderERP as SenderERP
    participant Gateway as APIGateway
    participant Validator as ValidationService
    participant Directory as DirectoryService
    participant Orchestrator as OrchestrationService
    participant Receiver as ReceiverEndpoint
    participant Audit as TrustService

    SenderERP->>Gateway: Submit JWE Message
    Gateway->>Gateway: Authenticate and authorize sender
    Gateway->>Validator: Structural validation
    Validator->>Validator: Semantic validation (message_id, sender_id, receiver_id, doc_type, timestamp)
    Validator-->>Gateway: Validation result
    Gateway->>Directory: Resolve receiver endpoint + doc capability
    Directory-->>Gateway: Endpoint + policy
    Gateway->>Orchestrator: Route payload
    Orchestrator->>Receiver: Deliver message
    Receiver-->>Orchestrator: Ack / Nack
    Orchestrator-->>SenderERP: Delivery result callback
    Orchestrator->>Audit: Record event trail

4) Key Subsystems and Responsibility

1. Channel Layer
2. Web Portal: UI สำหรับผู้ประกอบการจัดการสินค้าและติดตามสถานะ
3. Back-office: UI สำหรับ Admin/Support ทำ KYC, config, monitoring

4. API: สำหรับองค์กรที่มี ERP เชื่อมต่ออัตโนมัติ

5. API Gateway + Security

6. Token-based authentication (เช่น OAuth2/OIDC)
7. Authorization แบบ RBAC + policy checks

8. Rate limiting, request tracing, API monitoring

9. Directory Services

10. Participant Registry: participant ID, endpoint, public key, partner matching
11. Document Registry: matrix ว่าใครส่ง/รับเอกสารประเภทใดได้

12. Product Catalog Registry: สินค้า/รหัส/คำค้น/การกรอง

13. Orchestration & Validation

14. ตรวจสอบ schema และ business semantic rules
15. Routing ตาม metadata (doc_type, participant_id, transaction state)

16. ส่ง callback บอกสถานะสำเร็จ/ล้มเหลวพร้อมเหตุผล

17. Core Transaction Services

18. Order Management
19. Delivery Management
20. Invoice & Billing

21. Payment Confirmation

22. Trust/Support Services

23. Audit log (Who/What/When)
24. Notification (email/other channels)
25. Transaction viewer และ dashboard

5) Security Architecture Baseline

• Data in transit: TLS 1.2+ ทุกช่องทาง
• Payload confidentiality: รองรับ JWE ตาม requirement
• Key management: เก็บ public key ใน registry, รองรับ key rotation
• Access control: RBAC + least privilege
• Auditability: immutable audit trail + retention policy
• Admin activity logging: แยกและเข้มกว่าผู้ใช้ทั่วไป

6) Deployment Baseline (สำหรับการตีราคา)

สถาปัตยกรรมแนะนำแบบ containerized services: - Environment: dev, sit/uat, prod - Stateless services scale out ได้ที่ API Gateway/Orchestration/Validation - Database ใช้ managed relational DB + replica read - Search ใช้ managed search service - Queue/Event bus (optional in phase 2+) สำหรับ async routing/notification

7) Observability & Operations

• Centralized logging พร้อม correlation id (message_id, trace_id)
• Metrics: throughput, success rate, validation failure rate, routing failure rate
• Alerting: API error spike, endpoint down, queue lag (ถ้ามี queue)
• Dashboard: system health, daily/monthly transactions, new registrations

8) Vendor Estimation Work Packages

แนะนำให้ vendor แตกงานตาม package ต่อไปนี้: - Package A: Identity, KYC/KYB, RBAC, participant onboarding - Package B: Product registry + search/faceted filtering - Package C: Document lifecycle services (order/delivery/billing/payment) - Package D: API Gateway + validation + routing + callback - Package E: Back-office monitoring/audit/dashboard - Package F: DevOps, security hardening, observability, deployment

9) Assumptions / Out of Scope

Assumptions: - ERP ฝั่งคู่ค้าสามารถพัฒนา adapter ตาม API contract ได้ - ช่องทาง notification ขั้นต้นเริ่มจาก email ก่อน

Out of Scope: - Multi-region active-active architecture - Real-time stream analytics ขั้นสูง