Volume 1 · Business Context
เล่มนี้สังเคราะห์ ภาพธุรกิจ ของแพลตฟอร์ม VTRC จากสิ่งที่ Volume 3-10 ค้นพบระหว่างอ่านโค้ดของทั้ง 31 repository — ไม่ใช่จากเอกสาร requirement, org chart, หรือการสัมภาษณ์ผู้มีส่วนได้ส่วนเสีย เพราะ workspace นี้ไม่มีข้อมูลเหล่านั้นให้เข้าถึง ทุกข้อความในเล่มนี้จึงมาจากการอนุมานจากโค้ด (ชื่อ entity, ชื่อ endpoint, comment, business rule ที่เขียนไว้ใน validation) — จุดใดที่อนุมานได้แค่ระดับ hypothesis จะระบุ UNVERIFIED ไว้ชัดเจน ไม่เดาเติมให้ดูสมบูรณ์
Deep Redo (2026-07-14): ตาราง domain ด้านล่างยังถูกต้องหลัง V1-depth rewrite ของ Vol 3–9 — ถ้าต้องการรายละเอียด flow/entity ให้ไปที่ deep-dive ของ repo นั้นโดยตรง ไม่ต้องรอเล่มนี้ขยาย
ถ้าต้องการ business logic ระดับ flow/state-machine ที่ trace ได้เต็ม ให้ไปที่ Volume 14 · Business Logic & Workflows — Volume 1 นี้ตอบคำถามระดับกว้างกว่านั้นคือ "VTRC ทำธุรกิจอะไร" และ "ใครใช้ระบบ"
VTRC คืออะไร
VTRC คือแพลตฟอร์มซอฟต์แวร์ HR/Welfare ของสภากาชาดไทย (Thai Red Cross) ที่พนักงานใช้งานประจำวันสำหรับงาน HR (ดูสลิปเงินเดือน, ขอลา, เบิกสวัสดิการ) และที่ฝ่าย HR/Admin ใช้บริหารจัดการคำขอเหล่านั้น ระบบเริ่มต้นราวปี 2019 เป็น monolith 2 ตัว (vtrc-api + cu-central-api) แล้วขยายตัวต่อเนื่องจนถึงปัจจุบันที่มีบริการย่อยกระจายออกเป็น 31 repository ใน 7 กลุ่มแพลตฟอร์ม (ดู Volume 2 สำหรับภาพสถาปัตยกรรม)
ชื่อ "VTRC" ปรากฏเป็น prefix ของ repository ส่วนใหญ่ (vtrc-api, vtrc-web, vtrc-mobile ฯลฯ) และเป็น subdomain หลักที่ frontend ชี้ไป (vtrc.redcross.or.th, vtrcapi.redcross.or.th — ดู Canonical Truths § Environment & endpoint resolution)
ธุรกิจที่ทั้ง 31 repository รับใช้ร่วมกัน
จากการอ่าน index.md ของทุก volume ที่ deep-dive ไว้ สามารถจัดกลุ่ม business domain ที่แพลตฟอร์มรับใช้ได้เป็น 7 กลุ่มใหญ่ ตรงกับ platform group ทางเทคนิคเกือบทั้งหมด (ยกเว้นบางจุดที่ชื่อ repo ทำให้เข้าใจผิดว่าอยู่คนละ domain — ระบุไว้ในตารางด้วย):
| Business domain | Repository ที่รับผิดชอบ | หลักฐานจาก |
|---|---|---|
| Employee self-service (ดูสลิป, ขอลา, ข้อมูลส่วนตัว) | vtrc-api, vtrc-web, vtrc-mobile, new-vtrc-mobile | Volume 3 · vtrc-api, Volume 8 · Mobile |
| HR/Admin back office (อนุมัติคำขอ, จัดการข้อมูลองค์กร) | vtrc-rc-backoffice, vtrc-backoffice, vtrc-backoffice-new | Volume 4 · Web Frontends |
| สวัสดิการ/เบิกจ่าย (เยี่ยมโรงพยาบาล, ฌาปนกิจ, ทุนการศึกษา, ภัยพิบัติ) | benefit-api | Volume 6 · benefit-api |
| สรรหาบุคลากร (recruitment) | recruitment-api, ai-recruitment-api (สื่อ/กราฟิกสรรหาด้วย AI), recruitment-web (เว็บสมัครงานสาธารณะ) | Volume 6 · recruitment-api, Volume 9 · recruitment-web |
| บริหารผลการปฏิบัติงาน (performance management) | pms-api — repo ใหญ่สุดในกลุ่ม Domain Microservices | Volume 6 · pms-api |
| สื่อสารสองทาง (announcement/survey/complaint ผ่าน LINE OA) | 2way-api, 2way-batch, 2way-line-service, 2way-meeting-backoffice, 2way-vtrc-api | Volume 5 · 2way Platform |
| แชท/incident (chat center แอดมิน + LINE OA, แจ้งปัญหาการใช้งานระบบ) | chat-center-api, job-scheduler-api (cron สรุป incident รายวัน) | Volume 6 · chat-center-api |
| บริหารการประชุม (meeting) | meeting-vtrc-api, meeting-backoffice, meeting-backoffice-new | Volume 7 · Meeting Platform |
| OCR (ตั้งใจไว้ แต่ยังเป็น mock ทั้งหมด) | vtrc-ocr-api | Volume 9 · vtrc-ocr-api |
| AI course/health-checkup/IPD billing workflow | workflow-api (package name จริง ai-pms-nest — ครอบ 3 domain ที่ไม่เกี่ยวกันโดยตรง) | Volume 6 · workflow-api |
| SSO gateway ภายนอก | sso-api | Volume 6 · sso-api |
| บริการกลาง (address/bank/file) | vtrc-common — standalone microservice ไม่ใช่ shared library | Volume 6 · vtrc-common |
ข้อควรระวังเรื่องชื่อ repo ที่ทำให้เข้าใจผิดข้าม domain — 2way-meeting-backoffice (ชื่อมีคำว่า "meeting") ไม่มีความเกี่ยวข้องกับ Meeting Platform group เลย เป็น frontend ของ 2way Platform ล้วน ๆ (ดู Canonical Truths § 2way Platform) — ผู้อ่านใหม่ที่เดา business domain จากชื่อ repo อย่างเดียวจะเข้าใจผิดจุดนี้ได้ง่าย
ใครใช้ระบบ — ผู้ใช้แต่ละกลุ่มแพลตฟอร์ม
ตารางนี้สรุปจากสิ่งที่แต่ละ volume ระบุไว้เรื่อง target user ของ repo นั้น ๆ (ส่วนใหญ่อนุมานจาก route/permission ในโค้ด ไม่ใช่จาก user research):
| กลุ่มผู้ใช้ | ใช้งานผ่าน repo | สิ่งที่ทำได้ |
|---|---|---|
| พนักงานทั่วไป | vtrc-web, vtrc-mobile, new-vtrc-mobile | ดูสลิป, ขอลา, เบิกสวัสดิการ, ดูข่าว/ประกาศ |
| ผู้สมัครงาน (job applicant) ที่ยังไม่เป็นพนักงาน | recruitment-web | สมัครงานสาธารณะ ยืนยันตัวตนผ่าน OTP |
| ฝ่าย HR/Admin | vtrc-rc-backoffice, vtrc-backoffice, vtrc-backoffice-new, 2way-meeting-backoffice (แอดมิน), meeting-backoffice(-new) | อนุมัติคำขอลา/เบิกสวัสดิการ, ตั้งค่าองค์กร, จัดการประกาศ/แบบสำรวจ, ตั้งค่ากลุ่มผู้อนุมัติการประชุม |
| ผู้จัดประชุม/ผู้เข้าร่วมประชุม | meeting-vtrc-api/meeting-backoffice(-new) (ผ่าน token redirect จากระบบภายนอก) | ตั้งค่ากลุ่มประชุม, ค้นหา org, อนุมัติผู้เข้าร่วม |
| ทีมสรรหาบุคลากร | recruitment-api, ai-recruitment-api | บริหาร job request → candidate → contract, สร้างสื่อ/กราฟิกด้วย AI |
| ทีมผลการปฏิบัติงาน | pms-api (ผ่าน backoffice ที่เรียกใช้ — repo frontend ที่แน่ชัดยังไม่ได้ยืนยันในสโคปนี้ — UNVERIFIED) | ตัวชี้วัด, ประเมิน, อนุมัติ, ปรับเงินเดือน |
| ทีม incident/support ภายใน | chat-center-api, job-scheduler-api | แชท backoffice + LINE OA, สรุป incident รายวัน |
| นักพัฒนาฝึกงาน (i3dev) | interns_playground | sandbox ฝึกฝน — ไม่ใช่ผู้ใช้ปลายทางจริงของธุรกิจ VTRC ระบุไว้ชัดว่าไม่ใช่ production (ดู Volume 9 § interns_playground) |
ประวัติที่มองเห็นได้จากสถาปัตยกรรม — จาก monolith สู่ ~31 repository
หลักฐานทางโค้ดชี้ตรงกันว่า VTRC เริ่มต้นจาก Legacy Core 2 monolith คือ vtrc-api (Node.js + Apollo GraphQL + Sequelize + MariaDB) และ cu-central-api (LDAP/AD + MSSQL, เจ้าของข้อมูล HR ตัวจริง) — ดู Volume 3 · Legacy Core ที่บันทึกไว้ว่า vtrc-api มีขนาดโค้ด ~25,800 LOC ใหญ่ที่สุดในทั้งแพลตฟอร์ม และเป็น service เดียวที่ frontend ทุกตัวคุยด้วยตรง
หลักฐานของการค่อย ๆ แยกออกเป็น microservices (ไม่ใช่ big-bang rewrite):
centralize-api(NestJS, REST) ถูกสร้างเป็น HR data facade แบบอ่านอย่างเดียว แต่ Volume 3 พบว่า caller จริงยังไม่ยืนยัน (debt E-08) — เป็นสัญญาณว่ามีความพยายาม modernize อย่างน้อย 1 ครั้งที่อาจไม่ได้ integrate เข้าระบบเดินจริงสมบูรณ์- Domain Microservices ทั้ง 9 ตัว (
benefit-api,recruitment-api,pms-apiฯลฯ) แยกออกมารับผิดชอบงาน HR เฉพาะด้าน แต่ Volume 11 · Cross-service coupling พบว่าเกือบทุกตัวยังต่อฐานข้อมูลของvtrc-api/HRMI ตรง ไม่ผ่าน API — สะท้อนว่าการแยกเกิดที่ระดับ deploy/codebase ก่อน ไม่ใช่การออกแบบ data ownership ใหม่ตั้งแต่ต้น (ดู pattern "distributed monolith" ใน Volume 2 § architectural patterns) - 2way Platform และ Meeting Platform แยกออกมาเป็นกลุ่มใหม่ทั้งหมด (ไม่ได้ fork จาก legacy core) แต่ก็ยังผูกกับ
cu-central-api/centralize-apiเพื่อดึงข้อมูลพนักงาน (fetchListEmployeeForTwoWayถูกเรียกจาก 3 caller ต่างกลุ่ม — ดู Volume 13 § 13.3.3) — ยืนยันว่า legacy core ยังเป็น "แหล่งข้อมูลบุคคล" กลางของทั้งแพลตฟอร์มแม้ผ่านมาหลายปีของการแยก service
สมมติฐานเรื่อง 8 placeholder repos — Volume 10 พบว่ามี 8 repository (attendance-api, auth-api, career-api, hrservice-api, learning-api, notification-api, payroll-api, performing-api) ที่ไม่มีโค้ดเลยในทุก branch (มีเพียง .gitignore กับ 1 commit) ชื่อของ repo เหล่านี้สอดคล้องกับหมวดหมู่งาน HR ที่ ยังไม่มี service เฉพาะ ในแพลตฟอร์มปัจจุบัน และหลายชื่อทับซ้อนกับหน้าที่ที่ pms-api/benefit-api/workflow-api ทำอยู่แล้วจริงและ active มาก (pms-api เพียงตัวเดียวมี 376 ไฟล์ 1,900+ commits) — Volume 10 จึงตั้งเป็น hypothesis (ไม่ใช่ข้อเท็จจริงที่ verify ได้ตรง) ว่า repo เหล่านี้คือแผน microservices-split ที่วางไว้ล่วงหน้าตอนออกแบบสถาปัตยกรรม 7 กลุ่มแพลตฟอร์ม แต่ทีมเลือก implement ฟังก์ชันจริงเข้าไปใน service ที่มีอยู่แล้วแทนการสร้าง service ใหม่ตามชื่อที่วางไว้ — พูดอีกแบบคือ แผนการแยก microservices แบบเต็มรูปแบบดูเหมือนถูก "เปลี่ยนทาง" ไปสู่การขยาย service ที่มีอยู่แทน ไม่ใช่ถูกยกเลิกทั้งหมด (ทั้ง 8 repo ยังคงอยู่ใน Bitbucket ไม่ได้ถูกลบ)
ดูรายละเอียดเต็มของหลักฐานแต่ละจุดที่ Volume 10 § ตีความจากชื่อ repo และ Volume 2 § สถาปัตยกรรมที่วางแผนไว้แต่ยังไม่ implement
สิ่งที่เอกสารนี้ยืนยันไม่ได้ (UNVERIFIED โดยชัดแจ้ง)
Workspace นี้มีเพียง source code — ไม่มี PRD, org chart, roadmap เอกสาร, หรือช่องทางสัมภาษณ์ product owner/stakeholder จริง เนื้อหาต่อไปนี้จึงเป็นช่องว่างที่เล่มนี้ ไม่เดาเติม:
- จำนวนผู้ใช้จริง / KPI ทางธุรกิจ — ไม่มีหลักฐานจากโค้ดที่บอกขนาดผู้ใช้จริง (จำนวนพนักงานทั้งองค์กร, transaction volume ต่อวัน) นอกจาก schema/index ที่บอกเชิง technical capacity เท่านั้น
- เหตุผลทางธุรกิจเบื้องหลังการตัดสินใจแยก/ไม่แยก service — เช่นทำไม
vtrc-backoffice-newปิดเมนู "ข้อมูลองค์กร/หน่วยงาน" ที่vtrc-backofficeเดิมยังเปิดอยู่ (Volume 4 ระบุไว้ว่า "ไม่มีหลักฐานเหตุผลทางธุรกิจ") - สถานะ deploy จริงของ repo คู่ที่ดูเหมือนซ้ำกัน — เช่น
vtrc-backofficeยัง live คู่กับvtrc-backoffice-newหรือถูก decommission ไปแล้ว (Volume 4), หรือmeeting-backoffice/meeting-backoffice-newทั้งสองยังมีผู้ใช้จริงหรือไม่ (Volume 7) - แผน roadmap อย่างเป็นทางการของ 8 placeholder repos — ระบุไว้ชัดว่าเป็น hypothesis ในหัวข้อก่อนหน้า ไม่ใช่แผนที่ยืนยันจากผู้ดูแล architecture จริง
- Org structure ของฝ่าย HR สภากาชาดไทย — คำศัพท์อย่าง
orgCode, สาขากาชาด ที่ปรากฏในโค้ดบอกได้แค่ว่าระบบรองรับโครงสร้างแบบมีสาขา แต่ไม่รู้จำนวนสาขา/ลำดับชั้นการอนุมัติจริงนอกจากที่เขียนโค้ดไว้ตรง ๆ
จุดใดที่ต้องใช้ข้อมูลเหล่านี้เพื่อวางแผนจริง ควรยืนยันกับทีม HR/Operations/DevOps ที่ดูแลระบบอยู่ ก่อนใช้เนื้อหาในเล่มนี้เป็นฐานการตัดสินใจ
ขั้นตอนถัดไป
- อยากเห็นภาพสถาปัตยกรรมที่รองรับ business domain เหล่านี้ → ไป Volume 2 · Architecture & Topology
- อยากเห็น business flow แบบ end-to-end ข้าม repo (เช่น การเบิกสวัสดิการไหลผ่านตรงไหนบ้าง) → ไป Volume 14 · Business Logic & Workflows
- อยากรู้รายละเอียดของ repo ใด repo หนึ่งในตารางข้างต้น → ไปที่ Volume ของกลุ่มนั้นตรง (ดู Volume 0 § แผนที่ 7 กลุ่มแพลตฟอร์ม)