Kata: Silicon Sandwiches

Description

ร้านแซนด์วิชแห่งชาติแห่งหนึ่งต้องการเปิดให้สั่งซื้อออนไลน์ เพิ่มเติมจากบริการสั่งผ่านโทรศัพท์ที่มีอยู่แล้ว

Users

หลักพันคน และอาจถึงหลักล้านคนในวันหนึ่ง

Requirements

• อนุญาตให้ผู้ใช้สั่งซื้อ และหากร้านมีบริการจัดส่ง ให้เลือกได้ว่าจะรับเองหรือให้จัดส่ง

• แจ้งเวลารับสินค้าและเส้นทางไปยังร้านให้ลูกค้าที่มารับเอง (ซึ่งต้องผสานรวมกับบริการแผนที่ภายนอกหลายเจ้าที่มีข้อมูลการจราจรด้วย)

• สำหรับบริการจัดส่ง ให้ส่งคนขับพร้อมออร์เดอร์ไปหาผู้ใช้

• รองรับการเข้าถึงผ่านอุปกรณ์มือถือ

• เสนอโปรโมชันและของพิเศษประจำวันระดับประเทศ

• เสนอโปรโมชันและของพิเศษประจำวันระดับท้องถิ่น

• รับชำระเงินได้ทั้งออนไลน์ ที่ร้าน หรือเมื่อจัดส่งถึง

Additional context

• ร้านแซนด์วิชเป็นแฟรนไชส์ แต่ละร้านมีเจ้าของต่างกัน

• บริษัทแม่มีแผนขยายไปต่างประเทศในอนาคตอันใกล้

• เป้าหมายขององค์กรคือการจ้างแรงงานราคาถูกเพื่อเพิ่มกำไรสูงสุด

จากสถานการณ์นี้ คุณจะดึง architectural characteristics ออกมาได้อย่างไร? ข้อกำหนดแต่ละส่วนอาจมีส่วนเกี่ยวข้องกับแง่มุมหนึ่งหรือหลายแง่มุมของสถาปัตยกรรม (และหลายส่วนก็ไม่เกี่ยวข้องเลย) สถาปนิกไม่ได้ออกแบบระบบทั้งหมดในที่นี้—ยังต้องใช้ความพยายามอีกมากในการเขียนโค้ดเพื่อแก้ปัญหาด้านการออกแบบ domain (กล่าวถึงใน Chapter 8 ) แทนที่จะทำแบบนั้น ให้มองหาสิ่งที่มีอิทธิพลหรือส่งผลต่อการออกแบบ โดยเฉพาะในเชิงโครงสร้าง

ก่อนอื่น ให้แยก architectural characteristic ที่เป็นตัวเลือกออกเป็นคุณลักษณะแบบ explicit และ implicit

Explicit Characteristics (คุณลักษณะแบบ Explicit)

explicit architectural characteristics ปรากฏในเอกสารข้อกำหนดในฐานะส่วนหนึ่งของการออกแบบที่จำเป็น ตัวอย่างเช่น เว็บไซต์ช็อปปิ้งอาจตั้งเป้ารองรับผู้ใช้พร้อมกันจำนวนหนึ่ง ซึ่งนักวิเคราะห์ domain ระบุไว้ในข้อกำหนด ให้พิจารณาข้อกำหนดแต่ละส่วนว่ามีส่วนเกี่ยวข้องกับ architectural characteristic หรือไม่ แต่ก่อนอื่น ให้พิจารณาการคาดการณ์ระดับ domain เกี่ยวกับ metric ที่คาดหวัง ตามที่ระบุไว้ในส่วน Users ของ kata

รายละเอียดแรก ๆ ที่ควรสะดุดตาคุณคือจำนวนผู้ใช้ ปัจจุบันหลักพันคน และอาจถึงหลักล้านคนในวันหนึ่ง (นี่เป็นร้านแซนด์วิชที่ทะเยอทะยานมาก!) ดังนั้น scalability —ความสามารถในการรองรับผู้ใช้พร้อมกันจำนวนมากโดยไม่เสื่อม performance อย่างรุนแรง—จึงเป็นหนึ่งใน architectural characteristics อันดับต้น ๆ สังเกตว่าโจทย์ปัญหาไม่ได้ขอ scalability ตรง ๆ แต่แสดงข้อกำหนดนี้ผ่านจำนวนผู้ใช้ที่คาดหวังแทน สถาปนิกมักต้องแปลงภาษาของ domain ให้เป็นภาษาทางวิศวกรรมที่เทียบเท่ากัน

คุณอาจต้องการ elasticity ด้วยเช่นกัน—ความสามารถในการรองรับ request ที่พุ่งสูงขึ้นอย่างฉับพลัน คุณลักษณะทั้งสองนี้มักถูกจับรวมกัน แต่มีข้อจำกัดที่แตกต่างกัน Scalability มีลักษณะเหมือนกราฟที่แสดงใน Figure 5-1

Figure 5-1. Scalability คือการวัดการเพิ่มขึ้นของผู้ใช้ตามเวลา

ในทางกลับกัน Elasticity วัดการพุ่งขึ้นฉับพลันของ traffic ดังแสดงใน Figure 5-2

Figure 5-2. ระบบที่มี elasticity ต้องทนต่อ traffic ที่พุ่งขึ้นฉับพลันของผู้ใช้ได้

บางระบบมี scalability แต่ไม่มี elasticity ตัวอย่างเช่น จำนวนผู้ใช้ของระบบจองโรงแรม หากไม่มีโปรโมชันหรืออีเวนต์พิเศษ มักคาดการณ์ได้ตามฤดูกาล ในทางตรงกันข้าม ลองพิจารณาระบบจองตั๋วคอนเสิร์ต เมื่อตั๋วใหม่เปิดขาย แฟนคลับที่กระตือรือร้นจะแห่กันเข้ามาที่เว็บไซต์ ทำให้ต้องการ elasticity ระดับสูง บ่อยครั้งที่ระบบซึ่งมี elasticity ก็ต้องการ scalability ด้วยเช่นกัน คือความสามารถในการรองรับทั้ง traffic ที่พุ่งขึ้นและผู้ใช้พร้อมกันจำนวนมาก

Elasticity ไม่ปรากฏในข้อกำหนดของ Silicon Sandwiches แต่คุณก็ควรระบุมันไว้เป็นข้อพิจารณาที่สำคัญอยู่ดี บางครั้งข้อกำหนดก็ระบุ architectural characteristics ตรง ๆ แต่บางอย่างก็แอบซ่อนอยู่ใน problem domain traffic ของร้านแซนด์วิชคงที่ตลอดทั้งวัน หรือพุ่งขึ้นในช่วงเวลามื้ออาหาร? เกือบจะแน่นอนว่าเป็นแบบหลัง จึงควรระบุ architectural characteristic ที่เป็นไปได้นี้ไว้

ต่อไป ให้พิจารณาข้อกำหนดทางธุรกิจแต่ละข้อว่ามันเรียกร้อง architectural characteristics หรือไม่:

ผู้ใช้สั่งซื้อ และหากร้านมีบริการจัดส่ง ให้เลือกได้ว่าจะรับเองหรือให้จัดส่ง

ดูเหมือนจะไม่ต้องการ architectural characteristics พิเศษเพื่อรองรับข้อกำหนดนี้

ลูกค้าที่มารับเองจะได้รับแจ้งเวลาที่จะมารับแซนด์วิชและเส้นทางไปยังร้าน (ซึ่งต้องมีตัวเลือกในการผสานรวมกับบริการแผนที่ภายนอกที่มีข้อมูลการจราจร)

บริการแผนที่ภายนอกบ่งบอกถึงจุดผสานรวม ซึ่งอาจส่งผลต่อแง่มุมอย่าง reliability ตัวอย่างเช่น สมมติว่านักพัฒนาสร้างระบบที่พึ่งพาระบบของบุคคลที่สาม หากการเรียกใช้เหล่านั้นล้มเหลว ก็จะส่งผลต่อ reliability ของระบบที่เรียกใช้ ในทางกลับกัน ควรระวังการระบุ architectural characteristics มากเกินไป จะเกิดอะไรขึ้นถ้าบริการแผนที่ภายนอกล่ม? เว็บไซต์ Silicon Sandwiches ควรล่มตามไปด้วย หรือควรทำงานต่อโดยขาดข้อมูลการจราจรไปบ้าง? สถาปนิกควรระวังไม่ให้สร้างความเปราะบางหรือความไม่ยืดหยุ่นที่ไม่จำเป็นเข้าไปในการออกแบบเสมอ

สำหรับบริการจัดส่ง ให้ส่งคนขับพร้อมออร์เดอร์ไปหาผู้ใช้

ดูเหมือนจะไม่ต้องการ architectural characteristics พิเศษเพื่อรองรับ ข้อกำหนด นี้

รองรับการเข้าถึงผ่านอุปกรณ์มือถือ

ข้อกำหนดนี้จะส่งผลหลักต่อการออกแบบประสบการณ์ผู้ใช้ (UX) ของแอปพลิเคชัน และชี้ไปทางการสร้างเว็บแอปพลิเคชันแบบพกพา หรือแอปพลิเคชัน native หลายตัว เมื่อพิจารณาข้อจำกัดด้านงบประมาณและความเรียบง่ายของแอปพลิเคชัน การสร้างแอปพลิเคชันหลายตัวคงเกินความจำเป็น ดังนั้นการออกแบบจึงควรชี้ไปทางเว็บแอปพลิเคชันที่ปรับให้เหมาะกับมือถือ ดังนั้น คุณอาจต้องการนิยาม architectural characteristics ที่เกี่ยวข้องกับ performance บางอย่าง เพื่อปรับปรุงเวลาโหลดหน้าเว็บและคุณลักษณะอื่น ๆ ที่ไวต่อมือถือ

คุณไม่ควรตัดสินใจเรื่องแบบนี้เพียงลำพัง ให้ร่วมมือกับนักออกแบบ UX, domain stakeholder และผู้ที่เกี่ยวข้องอื่น ๆ เพื่อกลั่นกรองการตัดสินใจเหล่านี้ ตัวอย่างเช่น ธุรกิจอาจต้องการพฤติกรรมบางอย่างที่เป็นไปได้ก็ต่อเมื่อคุณสร้างแอปพลิเคชัน native เท่านั้น

เสนอโปรโมชันและของพิเศษประจำวันระดับประเทศ; เสนอโปรโมชันและของพิเศษประจำวันระดับท้องถิ่น

ข้อกำหนดทั้งสองนี้ระบุถึง customizability ทั้งในส่วนของโปรโมชันและของพิเศษ ข้อกำหนดที่ 1 ยังบ่งบอกถึงข้อมูลการจราจรที่ปรับแต่งตามที่อยู่ของผู้ใช้ด้วย จากข้อกำหนดทั้งสองนี้ คุณอาจพิจารณา customizability เป็น architectural characteristic ตัวอย่างเช่น รูปแบบสถาปัตยกรรมแบบ microkernel (กล่าวถึงใน Chapter 13 ) รองรับพฤติกรรมที่ปรับแต่งได้ดีเยี่ยม ด้วยการนิยามสถาปัตยกรรมแบบ plug-in ในกรณีนี้ พฤติกรรมเริ่มต้นจะอยู่ใน core ส่วนนักพัฒนาจะเขียนส่วนที่ปรับแต่งได้ตามพื้นที่เป็น plug-in อย่างไรก็ตาม การออกแบบแบบดั้งเดิมก็รองรับข้อกำหนดนี้ได้เช่นกันผ่าน design pattern (เช่น Template Method) ปัญหาแบบนี้พบได้ทั่วไปในสถาปัตยกรรม และต้องการให้สถาปนิกชั่งน้ำหนัก trade-off ระหว่างตัวเลือกที่แข่งขันกันอยู่ตลอดเวลา เราจะพูดถึง trade-off เฉพาะเจาะจงในรายละเอียดเพิ่มเติมใน “Design Versus Architecture and Trade-Offs”

รับชำระเงินได้ทั้งออนไลน์ ที่ร้าน หรือเมื่อจัดส่งถึง

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

ร้านแซนด์วิชเป็นแฟรนไชส์ แต่ละร้านมีเจ้าของต่างกัน

ข้อกำหนดนี้อาจกำหนดข้อจำกัดด้านต้นทุนให้กับสถาปัตยกรรม ให้ตรวจสอบความเป็นไปได้ (feasibility) โดยใช้ข้อจำกัดต่าง ๆ เช่น ต้นทุน เวลา และทักษะของทีมงาน เพื่อดูว่าสมควรใช้สถาปัตยกรรมแบบเรียบง่ายหรือ sacrificial architecture หรือไม่

บริษัทแม่มีแผนขยายไปต่างประเทศในอนาคตอันใกล้

ข้อกำหนดนี้บ่งบอกถึง internationalization (มักย่อว่า “i18n”) มีเทคนิคการออกแบบมากมายที่รองรับข้อกำหนดนี้ ซึ่งไม่ควรต้องการโครงสร้างพิเศษเพื่อรองรับ อย่างไรก็ตาม มันจะส่งผลต่อการตัดสินใจด้าน UX อย่างแน่นอน

เป้าหมายขององค์กรคือการจ้างแรงงานราคาถูกเพื่อเพิ่มกำไรสูงสุด

ข้อกำหนดนี้บ่งบอกว่า usability จะมีความสำคัญ แต่ก็เกี่ยวข้องกับการออกแบบมากกว่า architectural characteristics เช่นกัน

architectural characteristic ตัวที่สามที่เราสามารถดึงออกมาจากข้อกำหนดข้างต้นได้คือ performance ไม่มีใครอยากซื้อของจากร้านแซนด์วิชที่ performance แย่ โดยเฉพาะในช่วงเวลาเร่งด่วน อย่างไรก็ตาม performance เป็นแนวคิดที่มีรายละเอียดปลีกย่อยมาก คุณควรออกแบบเพื่อรองรับ performance แบบไหน กันแน่? (เราจะกล่าวถึงรายละเอียดปลีกย่อยต่าง ๆ ของ performance ใน Chapter 6 )

การนิยามตัวเลข performance ควบคู่ไปกับตัวเลข scalability ก็สำคัญเช่นกัน กล่าวอีกนัยหนึ่งคือ ให้กำหนด baseline ของ performance โดยไม่มี scale เฉพาะเจาะจงก่อน แล้วจึงกำหนดระดับ performance ที่ยอมรับได้เมื่อมีผู้ใช้จำนวนหนึ่ง บ่อยครั้งที่ architectural characteristics มีปฏิสัมพันธ์กัน ทำให้สถาปนิกต้องนิยามมันโดยสัมพันธ์กัน

Implicit Characteristics (คุณลักษณะแบบ Implicit)

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

Security ปรากฏเป็นคุณลักษณะแบบ implicit ในทุกระบบ ไม่มีใครอยากสร้างซอฟต์แวร์ที่ไม่ปลอดภัย อย่างไรก็ตาม คุณอาจให้ความสำคัญกับมันในระดับที่ต่างกันไป ขึ้นอยู่กับว่ามันสำคัญแค่ไหน ซึ่งแสดงให้เห็นถึงธรรมชาติที่เชื่อมโยงกันของนิยามของเรา คุณสามารถนับ security เป็น architectural characteristic ได้ ถ้ามันมีอิทธิพลต่อแง่มุมเชิงโครงสร้างบางอย่างของการออกแบบ และมีความสำคัญหรือจำเป็นต่อแอปพลิเคชัน

สำหรับ Silicon Sandwiches คุณอาจสมมติว่าการชำระเงินควรจัดการโดยบุคคลที่สาม ดังนั้น ตราบใดที่นักพัฒนาปฏิบัติตามสุขอนามัยด้าน security ทั่วไป (ไม่ส่งหมายเลขบัตรเครดิตแบบ plain text ไม่เก็บข้อมูลมากเกินไป และอื่น ๆ) การออกแบบที่ดีในแอปพลิเคชันก็เพียงพอแล้ว คุณไม่ควรต้องการการออกแบบเชิงโครงสร้างพิเศษเพื่อรองรับ security จำไว้ว่า architectural characteristics มีลักษณะ synergistic —แต่ละ architectural characteristic มีปฏิสัมพันธ์กับตัวอื่น ๆ นี่คือเหตุผลที่การระบุ architectural characteristics มากเกินไปเป็นกับดักที่พบได้บ่อย การระบุมากเกินไปสร้างความเสียหายพอ ๆ กับการระบุน้อยเกินไป เพราะมันทำให้การออกแบบระบบซับซ้อนเกินความจำเป็น

architectural characteristic หลักตัวสุดท้ายที่ Silicon Sandwiches ต้องการรองรับคือ customizability ซึ่งประกอบขึ้นจากรายละเอียดหลายอย่างในข้อกำหนด หลายส่วนของ problem domain มีพฤติกรรมที่ปรับแต่งได้ ได้แก่ สูตรอาหาร โปรโมชันท้องถิ่น และเส้นทางที่อาจถูกปรับเปลี่ยนตามท้องถิ่น ดังนั้น สถาปัตยกรรมควรรองรับพฤติกรรมที่ปรับแต่งได้ ปกติแล้วสิ่งนี้จะตกอยู่ในการออกแบบแอปพลิเคชัน อย่างไรก็ตาม ตามนิยามของเราที่ระบุไว้ เมื่อส่วนหนึ่งของ problem domain ต้องพึ่งพาโครงสร้างที่ปรับแต่งได้เพื่อรองรับ มันจะเข้าสู่ขอบเขตของ architectural characteristic อย่างไรก็ตาม องค์ประกอบการออกแบบนี้ไม่ได้สำคัญอย่างยิ่งต่อความสำเร็จของแอปพลิเคชัน จำไว้ว่าการเลือก architectural characteristics ไม่มีคำตอบที่ถูกต้อง มีแต่คำตอบที่ผิด—หรือ:

ไม่มีคำตอบที่ผิดในสถาปัตยกรรม มีแต่คำตอบที่แพงเท่านั้น

หนึ่งในคำพูดชื่อดังของ Mark