Communicating Design

Design ที่ไม่มีใครเข้าใจจะไม่ถูกสร้าง Design ที่ถูกสร้างแต่ไม่มีใครอธิบายได้จะไม่ได้งบ ไม่ได้อนุมัติ และไม่ได้ถูกดูแล การสื่อสารไม่ใช่ส่วนที่ soft ของงานนี้ — สำหรับ solution architect มันคือตัวงาน งาน design ทั้งหมดใน 19 บทก่อนกลายเป็นเรื่องจริงได้ผ่านบทนี้เท่านั้น

แปลตามผู้ฟัง#

Executive version 60 วินาที — จำรูปนี้ไว้#

"เรากำลังสร้าง X เพื่อให้ [ผลลัพธ์ทางธุรกิจ] วิธีการคือ [1 ประโยค] ต้นทุนประมาณ [ตัวเลข] และใช้เวลา [ระยะเวลา] ความเสี่ยงหลักคือ [ความเสี่ยง] และเราจัดการด้วย [การบรรเทา] trade-off ที่เรายอมรับคือ [สิ่งที่ยอมเสีย] เพราะ [เหตุผลที่รับได้] จากคุณผมต้องการ [การตัดสินใจ 1 ข้อที่เฉพาะเจาะจง]"

[!TIP] 6 ประโยค ฝึกพูดออกเสียงจนเป็นอัตโนมัติ ถ้าเติมช่องใดช่องหนึ่งไม่ได้ คุณยังไม่พร้อมนำเสนอ — และช่องที่ว่างนั้นบอกคุณตรงๆ ว่าต้องไปทำอะไรมาก่อน

Diagram ที่รอดการรีวิว#

ใช้ C4 model — 4 ระดับ และวาดเฉพาะระดับที่ผู้ฟังต้องการ

กฎ 7 ข้อของ diagram ที่ไม่ถูกรื้อในห้องรีวิว#

1. ทุกกล่องมีชื่อและมีจุดประสงค์ — "Service" ไม่ใช่ชื่อ · "Transfer Service — รับและบันทึกการเคลื่อนย้ายเงิน" คือชื่อ
2. ทุกลูกศรกำกับว่าอะไรไหลและไหลอย่างไร — HTTPS/JSON, sync, Kafka, async, at-least-once · ลูกศรที่ไม่มีป้ายซ่อนการตัดสินใจที่สำคัญที่สุดในหน้านั้น
3. ทิศทางหมายถึง dependency และต้องสม่ำเสมอ — การผสม "เรียก" กับ "ส่งข้อมูลไป" ใน diagram เดียวกันรับประกันว่า reviewer จะสับสน
4. แสดง trust boundary เป็น container เส้นประ — internet / DMZ / internal / ขอบเขตข้อมูลบัตร / partner · security และ audit อ่านอันนี้ก่อน และถ้าไม่มีเขาจะถาม
5. 1 diagram 1 คำถาม — diagram ที่ตอบ "การจ่ายเงินไหลอย่างไร" ไม่ใช่ diagram เดียวกับ "อะไร deploy อยู่ที่ไหน" · วาด 2 อัน
6. ใส่ legend และวันที่ และเก็บ source ไว้ข้างโค้ดเพื่อให้อัปเดตได้ — diagram ที่ไม่มีวันที่ใน wiki คือข้อมูลผิดภายใน 6 เดือน
7. Diagram as code (Mermaid, PlantUML, Structurizr) ถูกรีวิวใน pull request และคงความทันสมัย — ภาพวาดใน slide deck ไม่

System map

วินัยบนกระดาน (ทั้งในสัมภาษณ์และในประชุมจริง)#

LAYOUT — ใช้ layout เดิมทุกครั้ง เพื่อให้มือของคุณว่างพอที่จะคิดเรื่องโจทย์
แทนที่จะคิดเรื่องรูป

 ┌──────────────┬───────────────────────────────┬──────────────┐
 │ REQUIREMENTS │   ARCHITECTURE (อันใหญ่)      │  ESTIMATES   │
 │  functional  │                               │   QPS        │
 │  quality     │                               │   storage    │
 │  non-goals   │                               │   peak       │
 ├──────────────┤                               ├──────────────┤
 │ API/CONTRACT │                               │  DEEP DIVE / │
 │ DATA MODEL   │                               │  FAILURES    │
 └──────────────┴───────────────────────────────┴──────────────┘

6 ข้อที่ต้องทำระหว่างนั้น:

• เขียน requirement และ NON-GOAL ก่อน ไว้ที่มุมกระดาน และปล่อยให้มองเห็นตลอด — คุณจะชี้ไปที่มันทั้ง session
• บรรยายไปพร้อมกับที่วาด — "ผมวาง cache ที่นี่เพราะ pattern 1 คือ 300 read/s และทนความเก่าได้ 5 วินาที"
• เว้นที่ว่างไว้ — คุณจะต้องเพิ่มของ
• เวลาสมมติอะไร ให้พูดคำว่า "สมมติว่า" แล้วเขียนมันลงไป
• เวลาไม่รู้ ให้พูดว่า "ผมไม่รู้ นี่คือวิธีที่ผมจะหาคำตอบ" — ในประชุมจริงมันสร้างความเชื่อถือ ในการสัมภาษณ์ได้คะแนนสูงกว่าคำตอบผิดที่พูดอย่างมั่นใจ
• คุม session เอง — "เหลืออีก 15 นาที ผมอยากใช้มันกับ ledger กับเส้นทาง reconciliation อันนั้นมีประโยชน์ที่สุดไหม" · ทั้งผู้สัมภาษณ์และ stakeholder ตอบสนองดีกับ architect ที่บริหารเวลาอย่างชัดเจน

RFC template#

1 เอกสารต่อ 1 design ที่มีนัยสำคัญ เก็บใน version control ข้างโค้ด เป้าหมาย 3–6 หน้า — ถ้ายาวกว่านั้นไม่มีใครอ่าน และความยาวมักซ่อนการตัดสินใจที่ยังไม่ได้ตัดสิน

# RFC-021: Wallet-to-wallet transfers

Author · Reviewers · Status (Draft|In review|Approved|Superseded) · Date
Approval required from: <ตำแหน่งที่ระบุชื่อ สำหรับอะไรที่กระทบ production>

## 1. Summary (ไม่เกิน 5 ประโยค)
เรากำลังสร้างอะไร เพื่อใคร และวิธีการ 1 บรรทัด

## 2. Problem & context
ทำไมตอนนี้ · วันนี้มีอะไรอยู่ · อะไรพังหรือขาด · ลิงก์ไป business case
ใส่ตัวเลขที่ให้เหตุผลว่างานนี้ควรทำ

## 3. Goals / Non-goals
ชัดเจนและทดสอบได้
Non-goal เป็นหัวข้อที่มีค่าที่สุดในเอกสาร — มันคือสิ่งที่หยุด scope creep
ในอีก 6 สัปดาห์

## 4. Requirements
รายการ functional · quality attribute พร้อมตัวเลข (latency, availability,
consistency, durability, retention) · constraint
สำหรับทุก requirement ด้าน compliance หรือนโยบาย:
*แหล่งที่มา และใครยืนยัน พร้อมวันที่*

## 5. Proposed design
Context diagram แล้วต่อด้วย container diagram · API contract ·
data model พร้อม access pattern table ·
request trace ของ happy path และ failure path อย่างน้อย 2 เส้น

## 6. Alternatives considered
2-3 ทางเลือก พร้อมเหตุผลที่แพ้ · ต้องมี "ไม่ทำอะไร / ขยายระบบเดิม" ด้วย
เอกสารที่ไม่มีทางเลือกที่ถูกปฏิเสธอ่านเหมือนการตัดสินใจที่ไม่เคยเกิดขึ้นจริง

## 7. Trade-offs accepted
เรายอมเสียอะไร และทำไมมันรับได้ในบริบทนี้

## 8. Failure modes & operations
Failure table · SLO และ error budget · alert · ลิงก์ runbook ·
พฤติกรรมตอน degrade รวมถึง *ใครเป็นเจ้าของการตัดสิน fail-open/fail-closed* ·
kill switch

## 9. Security & privacy
Trust boundary · data classification · โมเดล authn/authz ·
การจัดการ secret · อะไรถูก log และอะไรถูก mask ·
retention และการลบ · threat ที่พิจารณาและที่อยู่นอก scope

## 10. Rollout & migration
กลยุทธ์ flag · ขั้นการ ramp พร้อม metric ที่เป็น gate ของแต่ละขั้น ·
เงื่อนไขและขั้นตอน rollback · แผน migrate ข้อมูล (expand-migrate-contract) ·
และวิธียืนยันความถูกต้องในแต่ละขั้น

## 11. Cost
ค่า infra รายเดือนโดยประมาณ และ cost per business event ถ้าทำได้

## 12. Open questions & decisions needed
ใครต้องตัดสินอะไร ภายในเมื่อไหร่ เพื่อให้โปรเจกต์เดินต่อได้
ให้เฉพาะเจาะจง — "Compliance ยืนยันระยะเวลา retention ภายใน 15 ส.ค."

## Appendix: ADR ที่เกิดจาก RFC นี้

Design review ที่ผลิตการตัดสินใจออกมาได้#

การ facilitate ที่ได้ผล:

• ถามว่า "อะไรจะต้องเป็นจริง เพื่อให้ design นี้เป็น design ที่ผิด"
• ถามคนที่ senior และเงียบที่สุดโดยตรง
• แยก "ผมไม่เห็นด้วย" ออกจาก "ผมไม่เข้าใจ" ให้เร็ว
• เมื่อ 2 คนกำลังเถียงกัน เรียกชื่อเกณฑ์ที่เขาไม่เห็นด้วยกันจริงๆ — "คุณกำลัง optimize เพื่อความเร็วในการส่งของ เขากำลัง optimize เพื่อ operability ที่นี่อันไหนสำคัญกว่า และใครเป็นคนตัดสิน"

รับ pushback#

Lab 20 และ Capstone#

Lab 20 (90 นาที)#

หยิบ design ที่ดีที่สุดของคุณจากLab 18 แล้วผลิต:

Peer scoring 2 ข้อ: สถานะของทุกคำกล่าวชัดไหม (verified / assumption / needs decision)? และ คำอธิบาย 2 แบบมีข้อเท็จจริงชุดเดียวกันไหม?

Capstone (1 วันเต็ม หรือ 1 สัปดาห์แบบ part-time)#

เลือกระบบจริงในองค์กรของคุณ — ในอุดมคติคืออันที่คุณไม่พอใจ แล้วผลิต RFC ที่ครบ:

• การประเมินสถานะปัจจุบัน พร้อมตัวเลขที่วัดได้
• Target design
• แผน migration ด้วย expand-migrate-contract หรือ strangler fig
• Failure table
• SLO
• Cost model พร้อม cost-per-transaction
• ADR 3 ฉบับ
• รายการการตัดสินใจที่คุณต้องการ จากคนที่ระบุชื่อ

นำเสนอใน 20 นาทีต่อคณะที่เล่นบท CTO, product owner และ risk officer