The Impact of Scoping (ผลกระทบของการกำหนดขอบเขต)
สถาปนิกสามารถใช้ scope ของ architectural characteristics เพื่อช่วยกำหนดขอบเขต service ที่เหมาะสม ตามที่แสดงโดยรวมใน decision tree ใน Figure 7-1 และอธิบายรายละเอียดเพิ่มเติมในขั้นตอนต่าง ๆ
Figure 7-1. A decision tree that uses architectural characteristics scope to help determine architectural style
Scoping and Architectural Style (การกำหนดขอบเขตและ Architectural Style)
การกำหนดขอบเขต quantum ของ problem domain ช่วยในการเลือก architectural style ว่า monolithic architecture หรือ distributed architecture เหมาะสมกว่ากัน ลองพิจารณาส่วนแรกของ decision chart ที่แสดงใน Figure 7-2
Figure 7-2. Choosing an appropriate architectural style based on architectural characteristics
อย่างที่เราพูดถึงใน Chapter 4 สถาปนิกต้องวิเคราะห์ architectural characteristics และ domain เพื่อกำหนด architectural style ที่เหมาะสมที่สุด ส่วนหนึ่งของการวิเคราะห์นี้คือการดูว่าโซลูชันต้องการกลุ่มของ architectural characteristics มากกว่าหนึ่งกลุ่มหรือไม่ ในขั้นตอนที่หนึ่งของ Figure 7-2 สถาปนิกจะกำหนดว่าระบบจะสำเร็จได้ด้วย architectural characteristics ชุดเดียวหรือไม่ หรือจำเป็นต้องมีมากกว่าหนึ่งกลุ่ม (ดูตัวอย่างใน "Kata: Going Green" )
ถ้าสถาปนิกพบว่า architectural characteristics ชุดเดียวก็เพียงพอแล้ว พวกเขาก็สามารถเลือก monolithic architecture ซึ่งช่วยลดจำนวนตัวเลือกที่ต้องตัดสินใจต่อไป ถ้าพวกเขาเลือก distributed architecture ขั้นตอนต่อไปคือการกำหนดขอบเขต quantum ของมัน ดังแสดงใน Figure 7-3
Figure 7-3. In distributed architectures, architects must choose the appropriate quantum boundaries
เรามีแนวทางสำหรับกำหนด granularity ไว้ใน Chapter 18 ขั้นตอนต่อไปคือการเลือกกลไก persistence ซึ่งเกี่ยวข้องกับ architecture ทั้งสองตระกูล ดังแสดงใน Figure 7-4
Figure 7-4. Both architecture styles generally require persistence of some kind
สำหรับ monolithic architecture ฐานข้อมูล monolithic เดียวมักเหมาะสมพอ architecture และฐานข้อมูลจะถูกพัฒนาและ deploy ไปพร้อมกันเป็นจังหวะเดียวกัน ขั้นตอนนี้ถือว่าจบสมบูรณ์ — สถาปนิกสามารถไปเลือก monolithic style ที่เหมาะสมที่สุดต่อไปได้
ในทางกลับกัน distributed architecture สามารถใช้ฐานข้อมูลเดียว (พบได้ทั่วไปใน event-driven architecture) หรือแบ่งข้อมูลตามแนว granularity ของ service (เหมือนใน microservices architecture) ยังเหลือขั้นตอนสุดท้ายอีกหนึ่งขั้น คือกำหนดประเภทของการสื่อสารระหว่าง quanta ว่าจะเป็น synchronous หรือ asynchronous (เราพูดถึงคำถามนี้อย่างละเอียดใน Chapter 15 ) โปรดจำไว้ว่า ในบางระบบ การเลือก synchronous communication อาจเปลี่ยนขอบเขต quantum ที่ถูกกำหนดผ่าน static coupling ได้ coupling ทั้งสองประเภทนี้มีปฏิสัมพันธ์กันบ่อยครั้ง
Kata: Going Green
ลองมาวิเคราะห์ปัญหาหนึ่งโดยใช้ architecture quantum เป็น scope สำหรับ architectural characteristics กัน ปัญหานี้ชื่อว่า Going Green แสดงไว้ใน Figure 7-5
คุณกำลังทำงานร่วมกับ Going Green (GG) ธุรกิจที่รีไซเคิลและขายต่ออุปกรณ์อิเล็กทรอนิกส์เก่า เช่น โทรศัพท์มือถือ ระบบของบริษัทใช้ทั้งตู้คีออสก์สาธารณะและเว็บไซต์ ซึ่งรันบนระบบเดียวกัน ผู้ใช้สามารถอัปโหลดหมายเลขรุ่นและสภาพของอุปกรณ์ตัวเอง แล้ว GG จะเสนอราคาให้ ถ้าผู้ใช้ยอมรับราคา พวกเขาสามารถนำอุปกรณ์ไปฝากที่ตู้คีออสก์ได้ หรือถ้าใช้ผ่านเว็บไซต์ GG จะส่งกล่องให้ผู้ใช้ส่งไปรษณีย์กลับมา เมื่อได้รับอุปกรณ์แล้ว GG จะประเมินสภาพและส่งเงินให้ผู้ใช้ จากนั้น GG จะประเมินมูลค่าของอุปกรณ์แล้วนำไปรีไซเคิลหรือขายต่อ ระบบของบริษัทยังผลิตรายงานและงานวิเคราะห์ข้อมูลอื่น ๆ ด้วย
Figure 7-5. Requirements overview for Going Green
เมื่อคุณวิเคราะห์ architectural characteristics คุณสังเกตเห็นกลุ่มที่แตกต่างกันสามกลุ่มก่อตัวขึ้น ดังแสดงใน Figure 7-6
Figure 7-6. The GG architectural characteristics analysis yields three clusters of capabilities
ส่วนที่เผชิญหน้าผู้ใช้สาธารณะต้องการ scalability , availability และ agility ส่วนงานฝ่ายหลังบ้านต้องการ security , data integrity และ auditability และส่วนการประเมินอุปกรณ์ต้องการ maintainability , deployability และ testability (ซึ่งรวมกันเป็น composite architectural characteristic ของ agility ) ทำไมส่วนการประเมินอุปกรณ์จึงต้องการ architectural characteristics ชุดแยกต่างหาก นี่เป็นตัวอย่างที่ดีของการที่ตัวขับเคลื่อนทางธุรกิจมาบรรจบกับข้อกังวลด้าน architecture โมเดลธุรกิจของ GG พึ่งพาการขายต่ออุปกรณ์อิเล็กทรอนิกส์มือสองที่มีมูลค่าสูงที่สุด และรุ่นใหม่ ๆ ก็ออกมาอย่างต่อเนื่อง ยิ่งพวกเขาอัปเดตการประเมินอุปกรณ์ได้เร็วเท่าไร พวกเขาก็ยิ่งสามารถนำอุปกรณ์รุ่นใหม่กว่า (และมีมูลค่าสูงกว่า) มาขายต่อได้มากเท่านั้น
คุณจะออกแบบระบบที่ตอบโจทย์เกณฑ์ทั้งหมดนี้ได้ไหม ทั้ง scalability, availability, security, data integrity, auditability, maintainability, deployability และ testability มันเป็นไปได้…แต่จะยากมาก architectural characteristics เหล่านี้มักขัดแย้งกันเอง ตัวอย่างเช่น การทำให้ deployability รวดเร็วจะยากขึ้นเมื่อคุณต้องให้ความสำคัญกับข้อกังวลฝ่ายหลังบ้านอย่าง auditability ไปพร้อมกัน และ UI ก็ต้องการ scalability ในระดับที่ต่างไปจากส่วนอื่น ๆ ของระบบอย่างมาก
แทนที่จะพยายามทำทุกอย่างพร้อมกัน คุณสามารถใช้กลุ่มของ architectural characteristics เป็นตัวนำทางในการแบ่ง quanta ได้ ใน Figure 7-7 เส้นประแสดงถึง architectural quantum แต่ละตัว การใช้ scope ของ characteristic เป็นตัวนำทางสำหรับ service granularity เป็นก้าวแรกที่ดีในการกำหนดชุด trade-off ที่เป็นประโยชน์ที่สุด (เราจะสำรวจหัวข้อนี้ต่อไปใน Chapter 18 )
