ทุกคนคุ้นชินกับ Functional Requirement กันอยู่แล้ว ซึ่งมันจะบอกว่า ระบบทำอะไรได้ (What)

แต่ Architecture Characteristics จะเป็นตัวที่บอกว่าระบบจะทำงานได้ดีแค่ไหน (How Well)

เปรียบเทียบก็เหมือนกับเราจะซื้อรถยนต์ Functional คือ รถต้องวิ่งได้ มี 4 ล้อ แอร์เย็น (ทุกคันทำได้เหมือนกัน)

แต่ Characteristics คือ รถคันนี้ประหยัดน้ำมันไหม (Performance/Cost), ปลอดภัยชนแล้วถุงลมกางไหม (Security/Reliability), หรือซ่อมง่ายหาอะไหล่ตามอู่ทั่วไปได้ไหม (Maintainability)

Architecture Characteristics (บางทีเรียก Quality Attributes หรือ NFR in architecture level) คือ คุณสมบัติของระบบที่สถาปัตยกรรมต้องรองรับ เพื่อให้ระบบอยู่ได้จริงใน production

มันคือคำที่ “ลึกกว่า NFR ทั่วไป” เพราะใช้เป็นตัวตัดสิน architecture design เลย

Characteristics ที่นิยมใช้

เราสามารถแบ่งออกมาได้เป็น 2 กลุ่มใหญ่ๆ คือ

1.ฝั่ง Operational (ขณะระบบทำงาน)

  • Performance: ระบบต้องตอบสนองไว (เช่น โหลดหน้าเว็บใน 1 วินาที)
  • Scalability: รองรับคนใช้งานเพิ่มขึ้นจาก 1,000 เป็น 100,000 คนพร้อมกันได้
  • Availability: ระบบต้องเปิดตลอดยี่สิบสี่ชั่วโมง ห้ามล่ม (เช่น ระบบธนาคาร)
  • Security: ป้องกันข้อมูลรั่วไหล และควบคุมสิทธิ์คนใช้งาน

2.ฝั่ง Structural (โครงสร้างหลังบ้าน/การพัฒนา)

  • Maintainability: โค้ดอ่านง่าย แก้ไขบั๊กหรือปรับปรุงได้เร็ว ไม่กระทบส่วนอื่น
  • Testability: เขียนเทสอัตโนมัติได้ง่าย มั่นใจได้ว่าแก้โค้ดแล้วระบบไม่พัง
  • Deployability: เอาโค้ดใหม่ขึ้นระบบได้บ่อยและปลอดภัย (ทำ CI/CD ง่าย)

เราจะหา Characteristics เจอได้ยังไง

เรามีหลากหลายวิธีในการค้นหา บางตัวลูกค้าจะเดินมาบอกเราตรงๆ (Explicit) เช่น ขอระบบเร็วๆ ไม่ล่ม แต่บางครั้งลูกค้าจะไม่พูดออกมา แต่ถ้าเราไม่ทำระบบจะมีปัญหาแน่ (Implicit) เช่น ระบบห้ามโดนแฮก, ห้ามล้ม เป็นต้น

Explicit vs. Implicit Characteristics

Explicit Characteristics ถูกเขียนหรือระบุไว้อย่างเป็นลายลักษณ์อักษรในความต้องการทางธุรกิจ (Requirements) หรือ ได้มาจากการพูดคุยกับผู้มีส่วนได้ส่วนเสีย (Stakeholders) โดยตรง มันจะจับต้องได้ และ มักจะมีตัวเลขชี้วัด (Metrics) ที่ชัดเจน

ลักษณะเด่น: มีระบุในเอกสารชัดเจน

ตัวอย่าง:

  • Performance: ระบบต้องรองรับการกดจ่ายเงินและตอบกลับภายใน 2 วินาที
  • Scalability: ระบบต้องรองรับผู้ใช้งานพร้อมกัน 50,000 คนในช่วงแคมเปญ 11.11
  • Availability: ระบบต้องเปิดใช้งานได้ 99.99% (ล่มได้ไม่เกิน 52 นาทีต่อปี)

Implicit Characteristics ไม่มีใครเขียนบอกไว้ในความต้องการ แต่ในฐานะ Engineer สิ่งนี้ "จำเป็นต้องทำ" เพราะมัน คือ มาตรฐานขั้นต่ำที่ระบบที่ดีต้องมี

หากไม่มีข้อเหล่านี้ แม้ระบบจะทำงานได้ตามโจทย์ แต่ก็อาจสร้างความเสียหายร้ายแรงในอนาคต

ลักษณะเด่น: ลูกค้า หรือ ฝ่าย business มักจะไม่พูดถึง (เพราะเขาคิดว่าเราต้องทำให้อยู่แล้ว) Engineer ต้องเป็นคนดึงมันออกมาเอง

เลือกแต่ละตัวลง domain ยังไง

การเลือกว่าแต่ละ domain ควรจะให้ความสำคัญเรื่องไหนบ้างนั้น ขึ้นอยู่กับแต่ละ domain เลย เพราะแต่ละ domain อาจให้ความสำคัญแต่ละเรื่องไม่เท่ากัน

เช่น

  • payments: ให้ความสำคัญเรื่อง Availability, Security

ถ้าหากเราไม่รู้ว่าจะเลือกยังไง มี 3 คำถามขั้นต่ำที่ต้องตอบให้ได้

1. Value สูงสุดของ Domain นี้ ในเชิงธุรกิจ คือ อะไร?

  • ความน่าเชื่อถือของตัวเลขเงิน เลือก Security / Reliability
  • ความเร็วในการส่งของให้ลูกค้า เลือก Performance

2. ถ้าสิ่งนี้พังหรือไม่มี ธุรกิจจะเจ๊งทันทีใช่หรือไม่?

  • ถ้าระบบล่มไป 5 นาทีแล้วโดนปรับเป็นล้าน เลือก Availability
  • ถ้าหน้าตาเว็บเปลี่ยนบ่อยทุกสัปดาห์ตามโปรโมชั่น แต่ล่มบ้างไม่เป็นไร เลือก Extensibility / Deployability

3. เรากำลังแข่งกับอะไร?

  • แข่งกับเวลาและการตลาด (ต้องออกฟีเจอร์ใหม่ทุกสัปดาห์) เลือก Deployability / Maintainability
  • แข่งกับจำนวนผู้ใช้งาน (คนแห่มาถล่มพร้อมกันช่วงสิ้นเดือน) เลือก Scalability / Elasticity

นี่น่าจะพอ guild ให้ได้ในระดับหนึ่งแล้ว

เมื่อเราได้ Architecture Characteristic แล้ว ต่อไปเราสามารถเอาไปเลือก Architecture Styles ได้