ประชุมวางแผน Tech Stack · 14 ก.ย. 2569
ภาพรวมระบบ โมดูล และ software component ทั้งโครงการตามกรอบการดำเนินงาน พร้อมเสนอ 3 แบบการแบ่งงานระหว่าง tech party และจุดที่ต้องตัดสินใจก่อนลงมือ
ระบบแบ่งเป็น 5 ชั้นตามกรอบการดำเนินงาน ข้อ 6.1 — e-Marketplace (หน้าร้านและระบบแกนกลาง) ยืนอยู่บน OCN (ชั้นเชื่อมต่อกลางที่ไม่ผูกขาด) และทั้งสองวางอยู่บนศูนย์ข้อมูลในประเทศไทย ชั้น Edge และชั้น Data/Runtime เป็นของใช้ร่วมกันทั้งระบบ
รายการนี้ผูกกับรหัสรายการงบประมาณจริงในชีต 5.2.1 ไม่ใช่รายการที่คิดขึ้นเอง — สิ่งที่ไม่มีในนี้คือสิ่งที่ไม่มีเงินจ่าย และสิ่งที่มีในนี้ต้องมีคนรับผิดชอบ
6.2.1.1 · Frontend / Backend Headless Engine
6.2.1.2 · e-KYC · OMS · e-Tax
6.2.1.3 · Search · Affiliate · Live
6.2.1.4 · Dashboard · Audit · Moderation
ชีต 5.2.4 · ศูนย์ข้อมูลในประเทศไทย
ชีต 5.2.5 · ติดตั้งในประเทศทั้งหมด
ชีต 5.2.2 · 24 เดือน
ชีต 5.2.3 · ผูกกับรอบส่งมอบ
OCN ไม่ใช่ REST proxy ธรรมดา โปรโตคอลการค้าแบบเปิดเป็น asynchronous ทั้งเส้น — คำสั่งที่ส่งไปได้กลับมาแค่ ACK ส่วนคำตอบจริงกลับมาเป็น callback คนละ request นี่คือเหตุผลทางเทคนิคที่ต้องมี message broker ไม่ใช่เพราะแพลตฟอร์มต่างประเทศเจ้าใดใช้
ข้อ 6.2.4 บังคับศูนย์ข้อมูลในประเทศไทย และข้อ 7 ห้ามงบลงทุน — ทุกอย่างต้องเป็นค่าเช่าหรือค่าบริการรายงวด ห้ามซื้อสิทธิ์ขาด ห้ามซื้อครุภัณฑ์ ข้อนี้ตัดตัวเลือกทางเทคนิคไปหลายตัวก่อนจะได้เทียบราคาด้วยซ้ำ
คอลัมน์สถานะคือสิ่งที่ต้องถกในที่ประชุม ไม่ใช่รายการเทคโนโลยี — ของที่ล็อกแล้วล็อกเพราะ TOR หรือเพราะงบเขียนไว้แล้ว ไม่ใช่เพราะชอบ
| ชั้น | ตัวเลือกที่เสนอ | สถานะ | เหตุผลที่ผูกไว้ / สิ่งที่ต้องชั่ง |
|---|---|---|---|
| Frontend | Next.js 16 App Router · TypeScript 5 · Tailwind 4 · Zustand + TanStack Query | ต้องตัดสิน | demo ใช้อยู่แล้วและผ่านการ pitch มาแล้ว แต่ยังไม่ผูกมัดระบบจริง — ต้องชั่งกับทีมที่จะรับงานจริงว่าถนัดตัวไหน |
| Backend | NestJS 11 · REST + OpenAPI 3.0 · Hexagonal (domain / application / adapter) | ต้องตัดสิน | demo บังคับ layer ด้วย dependency-cruiser lint อยู่แล้ว สิ่งที่ต้องล็อกคือหลักการ hexagonal ไม่ใช่เฟรมเวิร์ก — ถ้าเปลี่ยนตัว ต้องได้กลไกบังคับขอบเขตเทียบเท่า |
| ฐานข้อมูลหลัก | PostgreSQL 18 · RDS Primary/Standby ข้าม AZ · 16 vCPU / 2 TB | ต้องตัดสิน | สเปคและ HA ข้าม AZ ล็อกด้วย TOR 6.2.4.15 แล้ว แต่ตัวเครื่องยนต์ยังเลือกได้ — ข้อจำกัดคือต้องเป็น managed service ที่ True IDC มีให้ในไทย |
| Document store | PostgreSQL JSONB ในคลัสเตอร์เดิม หรือ MongoDB 3 โหนดแยก | ต้องตัดสิน | งบมี 3 โหนดรออยู่แล้ว ถ้าใช้ JSONB ได้ 3 โหนดนั้นเอาไปเสริม search หรือ worker ได้ · demo ใช้ MongoDB mock ซึ่งยังไม่ผูกมัดอะไร |
| Search | OpenSearch หรือ Elasticsearch 3 โหนด + Thai tokenizer | ต้องตัดสิน | ที่ล็อกคือ “ต้องมีคลัสเตอร์ค้นหาแยก 3 โหนด” เพราะสินค้า 300,000 รายการและ TOR บังคับ Advanced Algorithms — เลี่ยงด้วย full-text ของ PostgreSQL ที่สเกลนี้ไม่ได้ · บรรทัด 6.2.4.1.1 ระบุชื่อ OpenSearch ไว้แล้ว ถ้าจะเปลี่ยนตัวต้องแก้ข้อความในบรรทัดนั้นด้วย |
| Message broker | Managed Kafka (DMS) 3 broker × 300 GB — kafka.2u4g.cluster.small | ล็อกแล้ว | เขียนไว้ตรงตัวในบรรทัด 6.2.4.1.1 แล้ว ผูกเหตุผลกับข้อ 6.2.1.1 เรื่อง Webhook realtime และ No-Code · ราคา query จริง 372.75 USD/เดือน ≈ 13,600 บาท หรือราว 3.5% ของบรรทัด · โหนด Worker/Queue/Ingress 2 ตัวเป็น consumer คนละของกับ broker |
| Auth ผู้ใช้ | better-auth + JWT · Social Login ผ่าน Google และ Facebook | ต้องตัดสิน | ขอบเขตที่ TOR เขียนไว้คือสมาชิกและ Social Login เท่านั้น — การเชื่อม SME Profile ของ สสว. เป็นการส่งข้อมูลผู้ขายและยอดขาย ไม่ใช่ identity provider จึงไม่ผูกกับตัวเลือกนี้ |
| Auth พันธมิตร (OCN) | OAuth2 client-credentials + API key · scope ต่อ adapter | ต้องตัดสิน | จะใช้ตัวเดียวกับ auth ผู้ใช้หรือแยก authorization server — แยกจะสะอาดกว่าตอนตรวจรับ แต่เพิ่มของที่ต้องดูแล |
| CI/CD | GitLab CE หรือ Gitea self-host + Argo CD · Trivy scan | ต้องตัดสิน | demo ใช้ Google Cloud Build ซึ่งใช้ไม่ได้กับข้อบังคับศูนย์ข้อมูลในไทย · โหนด Observability/CI 2 ตัวรองรับไว้แล้ว |
| IaC | Terraform + Helm · environment แยกด้วย workspace | ต้องตัดสิน | ใครเป็นเจ้าของ state และใคร apply ได้ — ข้อนี้ตัดสินพร้อมกับเรื่องแบ่งงาน |
| Observability | Cloud Eye + APM · log collector บนโหนด System | ล็อกแล้ว | เก็บย้อนหลัง 90 วัน เปิด read-only ให้ สสว. ตาม TOR 6.2.4.16–6.2.4.17 |
| Repository | monorepo เดียว (turborepo + pnpm) หรือ แยก repo ต่อ party | ต้องตัดสิน | ข้อนี้กระทบการแบ่งงานมากที่สุด — ดูหัวข้อถัดไป |
| สัญญาระหว่างทีม | openapi.yaml + packages/types + orval codegen | ล็อกแล้ว | ทำงานอยู่แล้วใน demo — client ของ frontend generate จาก spec ไม่ได้เขียนมือ |
ข้อ 7 ของกรอบการดำเนินงานห้ามงบลงทุนตรงตัว — ห้ามค่าครุภัณฑ์ ห้ามค่าที่ดินและสิ่งก่อสร้าง ผลทางเทคนิคคือ ลิขสิทธิ์ซอฟต์แวร์ถาวรที่ใช้เกิน 1 ปีอาจถูกตีเป็นสินทรัพย์ไม่มีตัวตน ทุกเครื่องมือที่จะเลือกต้องเป็น subscription หรือค่าบริการรายงวด และคำว่า “ติดตั้ง” ควรเขียนเป็น “ค่าบริการออกแบบและตั้งค่า” ทั้งหมด ข้อนี้ตัดตัวเลือกที่ขายแบบ perpetual license ออกก่อนจะได้เทียบ feature
โมดูลใน TOR มีสิบกว่าตัว คำถามคือแต่ละโมดูลควรเป็นหน่วยที่ deploy แยกหรือไม่ — หัวข้อนี้วางสองแบบให้เทียบกันจริง ๆ ทั้งแบบ modular ที่รวมโมดูลไว้ในหน่วยเดียว และแบบ microservice ที่แตกทุกโมดูลออกจากกัน พร้อมราคาที่แต่ละแบบต้องจ่าย
ขอบเขตของโมดูลบังคับในโค้ดด้วย hexagonal และ lint ส่วนจำนวนหน่วยที่ deploy จริงมีแค่เท่าที่มีเหตุผลทางเทคนิครองรับ
เกณฑ์ที่ใช้ตัดสินว่าอะไรได้แยกมีข้อเดียว — แยกเมื่อการอยู่รวมกันสร้างปัญหาจริง ไม่ใช่แยกเพราะเป็นคนละโดเมน โดเมนที่ต่างกันจัดการด้วยโมดูลในโค้ดได้อยู่แล้ว สิ่งที่โมดูลจัดการไม่ได้คือโปรไฟล์การสเกล รูปแบบการเชื่อมต่อ และขอบเขตความปลอดภัยที่ต่างกัน
| หน่วย deploy | โมดูลข้างใน | เหตุผลที่แยก | โปรไฟล์การสเกล |
|---|---|---|---|
core-api | Identity · Consent & DSR · Catalog · Cart · Order · Payment · Commission · Marketing · Seller · e-Tax · Moderation · Reporting | ไม่แยก — ทั้งหมดอยู่ใน transaction เดียวกันของ checkout และใช้ข้อมูลชุดเดียวกัน แยกเมื่อไรได้ saga เมื่อนั้น | สเกลตาม traffic ผู้ใช้ · เพิ่ม replica ทั้งก้อน |
search-api | Indexing · Query · Ranking · Recommendation | เป็นภาระ read หนักที่พุ่งตอนแคมเปญ และเป็นเจ้าของคลัสเตอร์ค้นหาเพียงผู้เดียว ถ้าอยู่รวมจะลาก core ล่มไปด้วยตอน re-index | สเกลแยกตามคิวรี · re-index ไม่กระทบการสั่งซื้อ |
ocn-api | Gateway · Partner Auth · Registry · Adapter 5 ช่องทาง · Webhook Dispatcher | ผู้เรียกเป็นคนนอกองค์กร ใช้ auth คนละชุด (OAuth2 client-credentials ไม่ใช่ session ผู้ใช้) และมี quota รายพันธมิตร — เป็นขอบเขตความปลอดภัยคนละชั้น | สเกลตาม fan-out ของพันธมิตร ไม่ใช่ตามผู้ใช้ |
live-api | Live Session · Anchor & Schedule · Moderation realtime · ผูกตะกร้า | ถือ connection ค้างไว้นาน ซึ่งเป็นรูปแบบตรงข้ามกับ request สั้น ๆ ของ core และทำให้ rolling deploy ของ core ตัดไลฟ์ที่กำลังออกอากาศ | สเกลตามจำนวนไลฟ์พร้อมกัน · deploy คนละรอบ |
worker | Kafka consumer · งานตามเวลา · retry และ DLQ · sync ดัชนี · ส่ง e-Tax · สร้างรายงาน | ไม่รับ traffic จากภายนอกเลย งานยาวและล้มเหลวได้โดยผู้ใช้ไม่ต้องรอ ถ้าอยู่ใน core งานหนักจะกินทรัพยากรของหน้าเว็บ | สเกลตามความยาวคิว · ล้มแล้ว retry ได้ |
แตกทุกโมดูลในหัวข้อที่ 02 ออกเป็นบริการของตัวเอง แต่ละตัวมีฐานข้อมูล pipeline และวงจรปล่อยของตัวเอง ทีมที่เป็นเจ้าของบริการหนึ่งปล่อยของได้โดยไม่ต้องรอใคร
ตารางเทียบข้อดีข้อเสียมักอ่านแล้วเลือกไม่ได้ เพราะทุกข้อฟังดูมีเหตุผล จุดที่ความต่างกลายเป็นงานเขียนโค้ดจริงคือตรงนี้
| มิติ | แบบ A — modular | แบบ B — microservice |
|---|---|---|
| หน่วยที่ deploy | 7 | 16 ขึ้นไป |
| ฐานข้อมูล | PostgreSQL หนึ่ง instance · schema แยกตามโมดูล | อย่างน้อย 12 ฐานที่ห้ามอ่านข้ามกัน · ต้องมีวิธี sync ข้อมูลที่ใช้ร่วม |
| checkout | transaction เดียว rollback อัตโนมัติ | saga พร้อม compensating transaction ทุกขั้น |
| pipeline และ alert | 7 ชุด | 16 ชุด |
| ของที่ต้องมีเพิ่ม | ไม่มี | service discovery · mTLS · saga orchestrator · distributed tracing · config กระจาย |
| การสเกลจุดร้อน | ขยาย replica ทั้ง core แม้ร้อนแค่โมดูลเดียว | ขยายเฉพาะบริการที่ร้อน — ข้อได้เปรียบจริงของแบบ B |
| การแบ่งงาน 3 party | ต้องมีวินัย lint และ review ข้ามทีม ไม่งั้นโค้ดชนกัน | ขอบเขตชัดโดยธรรมชาติ แต่ละ party เป็นเจ้าของบริการและปล่อยของเอง — ข้อได้เปรียบจริงของแบบ B |
| ความเสี่ยงต่องวดที่ 2 | ต่ำ — เวลาส่วนใหญ่ลงไปที่ฟีเจอร์ | สูง — เดือนแรก ๆ หมดไปกับ infrastructure ที่ยังตรวจรับไม่ได้ |
| ตรวจรับตาม TOR | ส่งมอบเป็นระบบงาน ตรงกับที่ชีต 5.2.1 เขียนไว้ | ต้อง map บริการกลับเข้าบรรทัดงบเอง ซึ่งไม่ตรงกันหนึ่งต่อหนึ่ง |
| ต้นทุน compute | อยู่ในกรอบ 18 โหนดที่ตั้งงบไว้ | min replica และ sidecar ต่อบริการกินโหนดเพิ่ม ต้องคำนวณใหม่ก่อนยื่น |
| ทีมที่ต้องมี | platform engineer ที่ดูแลคลัสเตอร์ได้ | เพิ่มคนดูแล mesh · tracing · orchestrator แบบเต็มเวลา |
ข้อเสนอ: เริ่มด้วยแบบ A แต่อย่าเลือกเพราะกลัว microservice — ข้อได้เปรียบสองข้อของแบบ B เป็นเรื่องจริงและตรงกับโจทย์ของที่ประชุมนี้พอดี คือมันแบ่งงานสาม party ได้สะอาดกว่ามาก โดยไม่ต้องอาศัยวินัยของคนในการ review โค้ดข้ามบริษัท · สิ่งที่ทำให้ยังไม่คุ้มคือเวลา ไม่ใช่หลักการ งวดที่ 2 อยู่ที่ 31 ธันวาคม 2569 และของหกอย่างในแถบล่างของภาพที่ 5 ต้องเสร็จก่อนฟีเจอร์แรกจะขึ้นได้ · ทางที่แนะนำคือแบบ A ที่บังคับขอบเขตเข้มพอจะแตกทีหลังได้ — โมดูลคุยกันผ่าน port อยู่แล้ว ถ้าปีที่สองพบว่าโมดูลไหนร้อนจริงหรือทีมไหนชนกันจริง ค่อยยกออกไปเป็นบริการของตัวเอง ราคาถูกกว่าการแตกทั้งหมดตั้งแต่ยังไม่รู้ว่าจุดไหนจะร้อน
โครงสร้าง component เหมือนกันทั้งสามแบบ ต่างกันที่เส้นแบ่งความรับผิดชอบ — และเส้นที่ลากต่างกัน ทำให้ต้นทุนการประสานงานกับความเสี่ยงตอนตรวจรับต่างกันคนละเรื่อง
P1 แอป · P2 OCN+Admin · P3 Infra/Sec/Ops
openapi.yaml ระหว่าง P1↔P2 · event schema ของ OCN · P3 ส่งมอบ namespace, pipeline และ environment ให้อีกสองทีมใช้เป็นบริการP1 ผู้ซื้อ · P2 ผู้ขาย · P3 Admin+OCN
packages/types เป็นของกลาง มีเจ้าของคนเดียว · ตาราง ownership ของฐานข้อมูลรายตาราง · Cloud/Security/Ops แยกเป็นทีมกลางP1 Frontend · P2 Backend+OCN · P3 Infra/Sec/Ops
openapi.yaml เป็นสัญญาหลักเส้นเดียว generate client ด้วย orval · P3 ส่งมอบ platform เป็นบริการเหมือนแบบ Aข้อเสนอเพื่อเปิดวงถก: ใช้ แบบ A เป็นโครง แล้วยืมแบบ B มาแบ่งภายใน P1 — เพราะงวดส่งมอบและการตรวจรับของ สสว. ผูกกับชีต 5.2.x อยู่แล้ว การลากเส้นตามชั้นระบบทำให้ “ใครส่งมอบอะไร งวดไหน” ตรงกับเอกสารสัญญาโดยไม่ต้องแปลง ส่วนปัญหา P1 ใหญ่เกินไปแก้ด้วยการแบ่งภายในเป็นสาย ผู้ซื้อ / ผู้ขาย ตามแบบ B ซึ่งเป็นปัญหาที่จัดการภายในบริษัทเดียวได้ง่ายกว่าข้ามสัญญา · แบบ C ควรตัดทิ้ง ถ้าไม่ได้มีข้อจำกัดเรื่องคนที่บังคับจริง ๆ
หกอย่างนี้ต้องมีเจ้าของและต้องนิ่งก่อนใครเริ่มเขียนโค้ดบรรทัดแรกของระบบจริง ไม่ใช่ค่อยตกลงกันระหว่างทาง
| สัญญา | รูปแบบ | กติกาที่ต้องตกลง |
|---|---|---|
| API Contract | openapi.yaml เป็น single source of truth | แก้ spec ต้องผ่าน PR review ของทุก party ที่เรียกใช้ · client ทุกตัว generate ด้วย orval ห้ามเขียนมือ · breaking change ต้องขึ้น version ใหม่ ไม่แก้ของเดิม |
| Canonical Data Model | schema กลางของ Product · Order · Shop · Inventory · Shipment · Payment · Address | ทั้ง e-Marketplace และ adapter ทุกตัวพูดภาษาข้อมูลเดียว · adapter เป็นฝ่ายแปลงเข้าหาพันธมิตร ไม่ใช่ core ปรับตามพันธมิตร |
| Event Taxonomy | product.* · order.* · stock.* · shipment.* · payment.* · affiliate.conversion | ชื่อ event · payload · versioning · การรับประกัน at-least-once และ idempotency key ฝั่งผู้รับ |
| Shared TypeScript types | packages/types · packages/sdk · packages/ui | ใครมีสิทธิ์ merge · ปล่อยเวอร์ชันอย่างไร · ทีมอื่นอัปเดตตามภายในกี่วัน |
| Database ownership | ตารางแยกตาม bounded context | ห้ามอ่านเขียนข้ามขอบเขตโดยตรง ต้องผ่าน API หรือ event เท่านั้น · migration ต้อง review ข้ามทีม |
| Environment และ pipeline | Dev · Staging · UAT · สภาพแวดล้อมทดสอบโหลดแบบปิด · Production | ใครมีสิทธิ์ deploy ที่ชั้นไหน · gate อะไรบ้างก่อนขึ้น production (Trivy scan · lint สถาปัตยกรรม · test coverage · pentest ผูกกับ major release) |
เรียงตามผลกระทบ — ข้อที่ 1 ถึง 3 ตัดสินไม่ได้ในที่ประชุมนี้แปลว่าอีกหลายข้อตัดสินไม่ได้ตามไปด้วย
เลือกแบบ A / B / C หรือแบบผสม และตัดสินพร้อมกันว่าจะเป็น monorepo เดียวที่ทุก party ส่ง PR เข้ามา หรือแยก repo ต่อ party — สองเรื่องนี้แยกกันตัดสินไม่ได้ ถ้าแบ่งตาม domain แบบ B แล้วแยก repo หน้าบ้าน จะได้ Design System สามชุดทันที
ต้องการ: หัวหน้าทีมทั้ง 3 party + เจ้าของสัญญางบมีสองจุดที่ทำหน้าที่คล้ายกัน — API Gateway กลางที่ข้อ 6.2.1.1.5 (ชีต 5.2.1) และชั้น Gateway ของ OCN ถ้ารวมเป็น deployment เดียวจะประหยัดของที่ต้องดูแลแต่ผูกสองทีมเข้าด้วยกันตลอดโครงการ ถ้าแยกจะได้ขอบเขตความรับผิดชอบที่สะอาดกว่าตอนตรวจรับ แต่ต้องยอมมี policy สองชุด — ตัดสินพร้อมกับเส้นแบ่งงานในข้อ 1
ต้องการ: ทีมสถาปัตยกรรม + เจ้าของ OCNTOR ขัดกันเอง เกณฑ์ทดสอบข้อ 6.2.3 เขียนฐานข้อมูลร้านค้า 3,000 ร้าน แต่ตัวชี้วัดข้อ 5 ตั้งเป้า SME 80,000 ราย ต่างกัน 27 เท่า ตัวเลขนี้กำหนดทั้ง sizing ของ search, fan-out ของ OCN และจำนวนโหนด — ควรทำหนังสือถาม สสว. ให้ชัดก่อน ไม่ใช่เดา
ต้องการ: ทีมสถาปัตยกรรม + ผู้ประสานงาน สสว.ทั้ง Fortinet และ Palo Alto ไม่ประกาศรองรับสแตก Huawei ที่ True IDC ใช้ ทางออกที่เสนอคือวางบน True IDC Private/Dedicated Cloud แล้วเชื่อมด้วย Direct Connect — ต้องได้หนังสือรับรองการสนับสนุนร่วมจาก True IDC และผู้ผลิตก่อนยื่น ไม่งั้นเป็นความเสี่ยงที่ตรวจรับไม่ผ่าน
ต้องการ: ทีม security + จัดซื้องบมี 3 โหนดรออยู่แล้ว ถ้าใช้ JSONB ในคลัสเตอร์เดิมได้ 3 โหนดนั้นเอาไปเสริม search หรือ worker ได้ทันทีโดยไม่เพิ่มเงิน ถ้าจะแยก MongoDB ต้องมีเหตุผลทางเทคนิคที่มากกว่า “demo ใช้อยู่”
ต้องการ: ทีม backend + infrademo ใช้ Google Cloud Build ซึ่งใช้กับระบบจริงไม่ได้เพราะข้อบังคับศูนย์ข้อมูลในประเทศ โหนด Observability/CI 2 ตัวใน 6.2.4.1.1 รองรับ runner ไว้แล้ว เหลือแค่เลือกตัวและตกลงว่าใครดูแล
ต้องการ: P3 หรือทีมที่จะรับงาน inframonorepo ปัจจุบันมี 57 spec, hexagonal architecture ที่บังคับด้วย lint และ OpenAPI spec 161 KB ที่ใช้งานได้จริง — ต้องตัดสินว่าเป็นฐานของระบบจริงหรือเป็นแค่ prototype สำหรับ pitch คำตอบนี้เปลี่ยนประมาณการเวลาของงวด 2 ทั้งหมด
ต้องการ: ทุก partyบรรทัด 6.2.1.2.1 ผูกกับระบบของ สสว. โดยตรง ทั้งขาส่งข้อมูลผู้ขายเข้าไปและ API ส่งยอดขายกลับ ซึ่งเป็นฝั่งที่เราควบคุมเวลาไม่ได้ ต้องได้ schema, วิธียืนยันตัวตนระหว่างระบบ และสภาพแวดล้อมทดสอบตั้งแต่ก่อนเซ็นสัญญา ไม่ใช่รอถึงสปรินต์ที่จะทำ · และต้องตกลงฐานทางกฎหมายของการส่งข้อมูลส่วนบุคคลข้ามหน่วยงานพร้อมกันไปด้วย
ต้องการ: เจ้าของโมดูลผู้ขาย + ฝ่ายประสานงาน สสว.