2.2 · Topology diagram
บทนี้ให้ภาพรวมระดับ platform-group ของ "ใครคุยกับใคร" — ไม่ใช่การพิมพ์ซ้ำ 34 ความสัมพันธ์ที่ Volume 13 § 13.3 Inter-service map บันทึกไว้แล้ว (ไปดูตารางเต็มที่นั่นถ้าต้องการ endpoint/protocol ระดับ repo คู่หนึ่ง) แต่ตอบคำถามที่กว้างกว่า — กลุ่มไหนพึ่งพากลุ่มไหน hub อยู่ที่ไหน และ network-level call ต่างจาก database-level coupling อย่างไร
2.2.1 · ภาพรวมระดับ platform-group
┌─────────────────────┐
│ Web Frontends │
│ vtrc-web, -rc-bo, │
│ -backoffice(-new) │
└──────────┬───────────┘
│ GraphQL (apiKey + JWT)
┌──────────▼───────────┐
│ Mobile │
│ vtrc-mobile, │──────┐
│ new-vtrc-mobile │ │ GraphQL (เดียวกัน
└──────────┬───────────┘ │ แต่ endpoint เป็น
│ │ source constant)
▼ ▼
┌───────────────────────────────────┐
│ vtrc-api │ ◄── HUB #1
│ (Legacy Core — MariaDB) │ fan-in: 9
└──────┬───────────────────┬──────────┘
│ GraphQL/REST │ REST (vtrc-common)
▼ ▼
┌─────────────┐ ┌──────────────┐
│ cu-central- │◄─────┤ vtrc-common │
│ api │ │ (Domain MS) │
│ (HUB #2) │ └──────────────┘
│ fan-in: 4 │
└──┬───┬───┬───┘
│ │ │
┌─────────────┘ │ └──────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌─────────────┐ ┌───────────────┐
│ 2way Platform │ │ Meeting │ │ Domain Micro- │
│ 2way-api, │ │ Platform │ │ services │
│ 2way-vtrc-api │◄─┤ meeting-vtrc-│ │ benefit-api, │
│ (5 repo) │ │ api │ │ recruitment-*, │
└───────┬────────┘ └──────┬───────┘ │ pms-api, ... │
│ │ └───────┬───────┘
│ REST │ REST (getUserByCondition,│ HTTP + DB ตรง
│ (ข้ามกลุ่ม) │ ข้ามกลุ่ม) │ (ดู 2.2.3)
▼ ▼ ▼
┌───────────────┐ ┌──────────────┐ ┌──────────────┐
│ chat-center-api│ │ 2way-vtrc-api │ │ vtrc / HRMI │
│ (Domain MS, │ │ (ถูกเรียกจาก │ │ (schema ตรง) │
│ ข้ามกลุ่ม) │ │ Meeting ด้วย)│ └──────────────┘
└───────────────┘ └──────────────┘
┌───────────────┐ ┌──────────────────┐
│ OCR & Aux │ │ Mobile/Web/ │
│ recruitment- │◄─REST───┤ Frontends อื่น │
│ web │ │ (แยกเรียก │
└───────┬───────┘ │ recruitment-api │
│ REST │ ตรง ไม่ผ่าน core) │
▼ └──────────────────┘
┌───────────────┐
│ recruitment-api│ (Domain Microservices)
└───────────────┘อ่านภาพนี้อย่างไร — เส้นทึบคือ network call (HTTP/GraphQL/WebSocket) ที่ยืนยันจากโค้ด เส้นที่ผ่าน vtrc-api/cu-central-api คือเส้นทางที่ทุก platform group พึ่งพาเพื่อดึงข้อมูลพนักงาน (employee directory) แม้จะมี microservice ใหม่เกิดขึ้น 20+ ตัวหลังจากนั้นก็ตาม — ตรงกับข้อสรุปของ Volume 13 § 13.3.6
2.2.2 · Hub-and-spoke — จุดศูนย์กลางที่ยังไม่เคยเปลี่ยน
| Hub | Fan-in (caller ที่ยืนยัน) | Fan-out | ผลกระทบถ้าล่ม |
|---|---|---|---|
vtrc-api | 6 frontend + benefit-api + 2way-api (dead code) + meeting-vtrc-api = 9 | cu-central-api, hrmi-api legacy, Conicle LMS, FCM, centralize REST auth | ทุกฟีเจอร์ฝั่งพนักงานที่ผ่าน frontend/mobile หยุดทำงานทันที |
cu-central-api | vtrc-api, 2way-api, 2way-vtrc-api, meeting-vtrc-api = 4 | ไม่มี (ปลายทางคือ database/LDAP) | ข้อมูล HR จริง (profile/slip/leave) เข้าไม่ได้ทั้งระบบ — ไม่มี circuit breaker/timeout กันไว้ที่ vtrc-api |
2way-vtrc-api | 2way-meeting-backoffice, meeting-backoffice, meeting-backoffice-new = 3 (ข้าม 2 platform group) | cu-central-api, LINE Messaging API | ฝีเจอร์ 2way ฝั่งพนักงานทั้งหมด + endpoint ค้นหาพนักงานของ Meeting Platform หยุดทำงาน |
vtrc-common | benefit-api, vtrc-web, vtrc-rc-backoffice, vtrc-mobile = 4 | ไม่มี | address/bank dropdown + file upload ของ 4 repo หยุดทำงาน |
vtrc-api และ cu-central-api ยังเป็นจุดศูนย์กลางที่แท้จริงของทั้งแพลตฟอร์ม แม้ผ่านการแยกเป็น microservices มาหลายปี — นี่คือหลักฐานเชิงโครงสร้างที่สนับสนุนคำอธิบายใน Volume 1 § ประวัติที่มองเห็นได้จากสถาปัตยกรรม ว่าการแยก service ส่วนใหญ่เกิดที่ระดับ deploy/codebase ไม่ใช่การย้าย data ownership ออกจาก legacy core จริง
2.2.3 · Network call vs database coupling — สองภาพที่ต้องดูคู่กัน
ภาพ 2.2.1 แสดงเฉพาะ network-level call (34 เส้นที่ยืนยันใน Volume 13) — แต่แพลตฟอร์มนี้มีความสัมพันธ์อีกชั้นที่ไม่ผ่าน network เลย คือ service ที่เปิด connection ตรงไปที่ database ของอีก service ("distributed monolith" pattern — ดู 2.3) จำนวน 14 เส้น ที่ยืนยันจาก Volume 11 § 11.2:
Network-level (ผ่าน API, 34 เส้น) Database-level (ต่อ DB ตรง, 14 เส้น)
────────────────────────────── ──────────────────────────────
frontend/mobile → vtrc-api benefit-api → vtrc (MSSQL), hrmi
vtrc-api → cu-central-api workflow-api → vtrc, hrmi ×2, benefit×2
2way-api → 2way-line-service pms-api → dbWorkforce (10 module)
2way-meeting-bo → 2way-vtrc-api 2way-api → pms schema (cron)
meeting-vtrc-api → vtrc-api chat-center-api → 2way DB (synchronize:true ⚠)
...ดูตารางเต็มที่ Volume 13 chat-center-api → dbHRMI_Center
sso-api → dbHRMI_Center (temp table เดียวกัน)
recruitment-api ↔ ai-recruitment-api (recruitment_ai)
...ดูตารางเต็มที่ Volume 11 § 11.2ทั้งสองภาพต้องอ่านคู่กันเสมอ — ถ้าดูแค่ network call จะเห็นว่า benefit-api "เป็นอิสระ" จาก vtrc-api แต่ในความจริง benefit-api เขียนตรงเข้า schema vtrc ของ vtrc-api ผ่าน raw SQL ทำให้ทั้งสอง service ยังผูกกันแน่นในระดับ data แม้จะดู decoupled ในระดับ API
2.2.4 · Third-party ที่ไม่ใช่ repo ภายใน
นอกเหนือจาก 39 repo ในแพลตฟอร์ม ยังมี external SaaS ที่หลาย repo เชื่อมออกไปพร้อมกัน — สำคัญเพราะเป็น single point of failure ร่วมที่ไม่ได้อยู่ใน control ของทีม:
| External service | เรียกจาก (จำนวน repo) |
|---|---|
| LINE Messaging API | vtrc-api, 2way-api, 2way-vtrc-api, chat-center-api (4 repo) |
| SMTP (Outlook) | recruitment-api, pms-api, meeting-vtrc-api, vtrc-api (4 repo) |
| Sentry | 2way-vtrc-api, meeting-vtrc-api, meeting-backoffice, 2way-meeting-backoffice (4 repo) |
| OpenAI / remove.bg / qrserver.com | ai-recruitment-api |
| AI Router (ManageAI) | workflow-api |
| SSO ภายนอก | sso-api, 2way-api |
รายละเอียดเต็มที่ Volume 13 § 13.3.5