Volume 2 · Architecture & Topology
เล่มนี้ตอบคำถามเดียว — "ระบบ VTRC มีโครงสร้างเป็นอย่างไรถ้ามองจากข้างบน" โดยสังเคราะห์จากทุกอย่างที่ Volume 3-10 (per-service deep dive) และ Volume 11-13 (cross-cutting synthesis) ค้นพบไว้แล้ว — เล่มนี้ไม่ re-explore โค้ดจากศูนย์ ทุก fact อ้างอิงกลับไปยัง volume ต้นทาง ยกเว้นจุดที่ต้อง cross-check ระดับภาพรวมเอง ซึ่งจะระบุไว้ชัดเจน
Deep Redo (2026-07-14): Topology และ hub (
vtrc-api/cu-central-api) ในบท 2.1–2.3 ยังเป็นภาพที่ถูกต้องหลัง deep rewrite — finding เชิง security ที่กระทบสถาปัตยกรรม (เช่น shared JWT, cross-DB coupling, backdoors) อัปเดตที่ Vol 12.5 และ Vol 18
Volume 1 เล่าในมุมธุรกิจ (ใครใช้ ทำไม) เล่มนี้เล่าในมุมวิศวกรรม — กี่บริการ ใครคุยกับใคร ใครต่อ database ของใครตรง และ pattern สถาปัตยกรรมแบบไหนที่เกิดขึ้นซ้ำจนกลายเป็นลักษณะเฉพาะของแพลตฟอร์มนี้
สารบัญ
| บท | หัวข้อ | คำถามที่ตอบ |
|---|---|---|
| 2.1 | 7 กลุ่มแพลตฟอร์ม | แต่ละกลุ่มมี repo อะไร stack จริงคืออะไร ต่างจากที่ docs/index.md เคยระบุไว้ตรงไหน |
| 2.2 | Topology diagram | กลุ่มไหนคุยกับกลุ่มไหน hub service อยู่ที่ไหน |
| 2.3 | Architectural patterns | pattern สถาปัตยกรรมที่พบซ้ำข้ามทั้งแพลตฟอร์มมีอะไรบ้าง |
ใครควรอ่าน
- Engineer ใหม่เข้าทีม — อ่านทั้ง 3 บทตามลำดับ จะได้แผนที่ก่อนไปเจาะลึก Volume 3-10
- Architect ที่วางแผน modernization — เริ่มที่ 2.3 เพื่อเห็น root cause เชิงโครงสร้าง แล้วย้อนไปดู topology ใน 2.2
- ผู้ประเมินความเสี่ยง — 2.2 บอกว่า service ไหนล่มแล้วกระทบใครบ้าง ใช้ประกอบกับ Volume 12 · Security
สิ่งที่ Volume 2 ไม่ทำ
- ไม่เจาะลึกโค้ดของแต่ละ repo — อยู่ใน Volume 3-10
- ไม่ลงรายละเอียด schema/database ระดับตาราง — อยู่ใน Volume 11 · Data Model
- ไม่ลง security finding แบบเจาะลึก — อยู่ใน Volume 12 และ Volume 18
- ไม่ให้ runbook ฉุกเฉิน — อยู่ใน Volume 16 · Operational Runbooks
ตัวเลขที่ควรจำ
| ตัวเลข | ค่า | ที่มา |
|---|---|---|
| Repository ที่มีโค้ดจริง | 31 (7 กลุ่ม) | repo fact-sheet index |
| Repository placeholder (ไม่มีโค้ด) | 8 | Volume 10 |
| Inter-service call relationship ที่ยืนยันจากโค้ด | 34 | Volume 13 § 13.3 |
| Cross-service database coupling (ไม่ผ่าน API) | 14 เส้น | Volume 11 § 11.2 |
| Datastore engine ที่พบทั้งแพลตฟอร์ม | 6 (MariaDB, MSSQL, MongoDB, PostgreSQL, LDAP/AD, local disk/SFTP) | Volume 11 § 11.1 |
| Hub service ที่มี fan-in สูงสุด | vtrc-api (9 caller), cu-central-api (4 caller) | Volume 13 § 13.3.6 |
Placeholder repos — สถาปัตยกรรมที่วางแผนไว้แต่ยังไม่ implement
ภาพสถาปัตยกรรมของแพลตฟอร์มนี้จะไม่สมบูรณ์ถ้าไม่พูดถึงสิ่งที่ วางแผนไว้แต่ไม่มีโค้ด — มี 8 repository (attendance-api, auth-api, career-api, hrservice-api, learning-api, notification-api, payroll-api, performing-api) ที่มีเพียง .gitignore กับ 1 commit ("Initial commit") ในทุก branch ไม่มีหลักฐานว่าเคย implement โค้ดจริงเลย (ดู Volume 10 สำหรับหลักฐานการตรวจสอบแต่ละ repo)
ชื่อของ repo เหล่านี้บอกใบ้ hypothesis ว่าเป็นแผน microservices-split ที่วางไว้ล่วงหน้าตอนออกแบบ 7 กลุ่มแพลตฟอร์ม แต่ทับซ้อนกับหน้าที่ที่ pms-api (performance), benefit-api (welfare/benefit), และ workflow-api (บาง feature) รับผิดชอบอยู่แล้วจริงในปัจจุบัน — ถ้ามองสถาปัตยกรรมแบบ "ควรจะเป็น" ตามชื่อ repo ที่วางไว้ แพลตฟอร์มนี้อาจถูกออกแบบมาให้มีอย่างน้อย 39 microservices แยกตาม domain ชัดเจน แต่สถาปัตยกรรม "ที่เป็นจริง" ตอนนี้คือ 31 repo ที่บาง service ครอบหลาย domain ไว้ในตัวเดียว (workflow-api ครอบ 3 domain ที่ไม่เกี่ยวกันโดยตรง — ดู Canonical Truths § Domain Microservices)
ไม่ควรถือว่า placeholder repos เหล่านี้เป็นหนี้ทางเทคนิคหรือความเสี่ยง — เป็นเพียงบันทึกสถานะแผนงานที่ยังไม่ implement (Volume 10 จึงไม่มี debt ID หรือ scorecard ให้)