Architectural Characteristics and System Design (Architectural Characteristics กับการออกแบบระบบ)

ในการจะถูกนับว่าเป็น architectural characteristic หนึ่ง ข้อกำหนดหนึ่งต้องผ่านเกณฑ์สามข้อ นั่นคือ ต้องระบุข้อพิจารณาการออกแบบที่ไม่ใช่ domain ต้องมีอิทธิพลต่อแง่มุมเชิงโครงสร้างบางอย่างของการออกแบบ และ ต้องมีความสำคัญหรือจำเป็นอย่างยิ่งต่อความสำเร็จของแอปพลิเคชัน ส่วนประกอบที่เชื่อมโยงกันเหล่านี้ในนิยามของเราแสดงไว้ใน Figure 4-2 ซึ่งประกอบด้วยสามองค์ประกอบนี้และตัวปรับแต่งอีกไม่กี่ตัว

Figure 4-2. คุณลักษณะที่แยกแยะ architectural characteristics ออกจากสิ่งอื่น

มาดูรายละเอียดของแต่ละองค์ประกอบกัน:

Architecture characteristic ระบุข้อพิจารณาการออกแบบที่ไม่ใช่ domain

การออกแบบเชิงโครงสร้างในสถาปัตยกรรมซอฟต์แวร์ประกอบด้วยกิจกรรมสองอย่างของสถาปนิก คือการเข้าใจ problem domain และการค้นหาว่าระบบต้องรองรับความสามารถแบบไหนบ้างจึงจะประสบความสำเร็จ ข้อพิจารณาการออกแบบด้าน domain ครอบคลุมพฤติกรรมของระบบ ส่วน architectural characteristics นิยามความสามารถ เมื่อรวมสองกิจกรรมนี้เข้าด้วยกันจะได้การออกแบบเชิงโครงสร้าง

ในขณะที่ design requirement ระบุว่าแอปพลิเคชัน ควรทำ อะไร architectural characteristics จะระบุ วิธี ที่จะ implement ข้อกำหนดเหล่านั้น และ เหตุผล ที่เลือกทางเลือกบางอย่าง กล่าวโดยสรุปคือ เกณฑ์ด้านการทำงานและการออกแบบเพื่อให้โปรเจกต์ประสบความสำเร็จ

ตัวอย่างเช่น ระดับ performance ที่เฉพาะเจาะจงมักเป็น architectural characteristic ที่สำคัญ แต่มักไม่ปรากฏในเอกสารข้อกำหนด ที่เกี่ยวข้องยิ่งไปกว่านั้นคือ ไม่มีเอกสารข้อกำหนดใดที่ระบุตรง ๆ ว่าการออกแบบต้อง “ป้องกัน technical debt” แต่มันก็เป็นข้อพิจารณาการออกแบบที่พบได้ทั่วไป เราจะกล่าวถึงความแตกต่างระหว่างคุณลักษณะแบบ explicit และ implicit อย่างละเอียดใน “Extracting Architectural Characteristics from Domain Concerns ”

Architecture characteristic มีอิทธิพลต่อแง่มุมเชิงโครงสร้างบางอย่างของการออกแบบ

เหตุผลหลักที่สถาปนิกพยายามอธิบาย architectural characteristics ในโปรเจกต์ต่าง ๆ ก็เพื่อดึงข้อพิจารณาการออกแบบที่สำคัญออกมา สถาปนิกสามารถ implement มันผ่านการออกแบบได้หรือไม่ หรือ architectural characteristic นี้ต้องอาศัยการพิจารณาเชิง โครงสร้าง เป็นพิเศษจึงจะสำเร็จ?

ตัวอย่างเช่น security เป็นประเด็นที่พบในแทบทุกโปรเจกต์ และทุกระบบต้องมีมาตรการป้องกันขั้นพื้นฐานระหว่างการออกแบบและการเขียนโค้ด อย่างไรก็ตาม security จะยกระดับขึ้นเป็น architectural characteristic เมื่อสถาปนิกตัดสินว่าสถาปัตยกรรมต้องการโครงสร้างพิเศษเพื่อรองรับมัน

ลองพิจารณา architectural characteristics ที่พบบ่อยสองตัว คือ security และ scalability สถาปนิกสามารถรองรับ security ในระบบแบบโมโนลิธได้ด้วยสุขอนามัยการเขียนโค้ดที่ดี รวมถึงเทคนิคที่รู้จักกันดี เช่น encryption, hashing และ salting (Architectural fitness function ซึ่งอยู่ภายใต้ร่มนี้ด้วย จะกล่าวถึงใน Chapter 6 ) ในทางกลับกัน ในสถาปัตยกรรมแบบกระจาย เช่น microservices สถาปนิกจะต้องสร้าง service ที่แข็งแกร่งขึ้น พร้อม access protocol ที่เข้มงวดกว่า—ซึ่งเป็นแนวทางเชิงโครงสร้าง ดังนั้นสถาปนิกจึงสามารถรองรับ security ได้ทั้งผ่านการออกแบบหรือผ่านโครงสร้าง ในทางกลับกัน ลองพิจารณา scalability ไม่ว่าการออกแบบจะฉลาดแค่ไหน ก็ไม่สามารถทำให้สถาปัตยกรรมแบบโมโนลิธ scale ได้เกินจุดหนึ่ง เมื่อพ้นจุดนั้นไป ระบบต้องเปลี่ยนไปใช้สถาปัตยกรรมแบบกระจายแทน

สถาปนิกให้ความสนใจอย่างใกล้ชิดกับ operational architectural characteristics (กล่าวถึงใน “Operational Architectural Characteristics” ) เพราะเป็นคุณลักษณะที่มักต้องการการรองรับเชิงโครงสร้างเป็นพิเศษมากที่สุด

Architecture characteristic ต้องมีความสำคัญหรือจำเป็นอย่างยิ่งต่อความสำเร็จของแอปพลิเคชัน

แอปพลิเคชัน สามารถ รองรับ architectural characteristics ได้เป็นจำนวนมาก...แต่ก็ไม่ควรทำเช่นนั้น architectural characteristic แต่ละตัวที่ระบบรองรับจะเพิ่มความซับซ้อนให้การออกแบบ นี่คือเหตุผลที่สถาปนิกควรมุ่งเลือก architectural characteristics ให้ น้อยที่สุด เท่าที่จะทำได้ แทนที่จะเลือกให้มากที่สุด

เราแบ่ง architectural characteristics ออกเป็นแบบ implicit และ explicit แบบ implicit แทบไม่ปรากฏใน requirement เลย แต่ก็จำเป็นต่อความสำเร็จของโปรเจกต์ Availability, reliability และ security เป็นรากฐานของแทบทุกแอปพลิเคชัน แต่แทบไม่เคยถูกระบุไว้ในเอกสารการออกแบบ สถาปนิกต้องใช้ความรู้เรื่อง problem domain เพื่อค้นหา architectural characteristics เหล่านี้ในช่วงวิเคราะห์ ตัวอย่างเช่น บริษัท high-frequency trading อาจไม่ต้องระบุ low latency ในทุกระบบ เพราะสถาปนิกใน problem domain นั้นรู้อยู่แล้วว่ามันสำคัญแค่ไหน ส่วน explicit architectural characteristics จะปรากฏในเอกสารข้อกำหนดหรือคำสั่งเฉพาะอื่น ๆ

ใน Figure 4-2 การเลือกใช้รูปสามเหลี่ยมนั้นตั้งใจ—แต่ละองค์ประกอบของนิยามสนับสนุนซึ่งกันและกัน ซึ่งจะสนับสนุนการออกแบบโดยรวมของระบบต่อไป จุดหมุน (fulcrum) ที่เกิดจากรูปสามเหลี่ยมนี้แสดงให้เห็นว่า architectural characteristics เหล่านี้มักมีปฏิสัมพันธ์กันอย่างไร นี่คือเหตุผลที่สถาปนิกใช้คำว่า trade-off บ่อยมาก