Case Study: Going, Going, Gone—Discovering Components (กรณีศึกษา: Going, Going, Gone — การค้นหา Component)

ถ้าทีมไม่มีข้อจำกัดพิเศษและกำลังมองหาการแบ่ง component แบบทั่วไปที่ดี แนวทาง Actor/Actions ก็ใช้ได้ดีในฐานะโซลูชันทั่วไป

ถ้าสถาปนิกนำแนวทาง Actor/Action มาใช้กับ Going, Going, Gone (GGG) พวกเขาจะพบว่าระบบนี้มีบทบาทหลักสามอย่าง คือ bidder (ผู้ประมูล), auctioneer (ผู้ดำเนินการประมูล) และ system — ผู้เข้าร่วมที่พบบ่อยในเทคนิคการสร้างโมเดลนี้สำหรับการกระทำภายใน บทบาทเหล่านี้ปฏิสัมพันธ์กับระบบผ่านการกระทำหลักต่อไปนี้

Bidder

• ดูวิดีโอสตรีมสด

• ดูสตรีมการประมูลสด

• เสนอราคา

Auctioneer

• ป้อนราคาประมูลสดเข้าระบบ

• รับราคาประมูลออนไลน์

• ทำเครื่องหมายว่าสินค้าถูกขายแล้ว

System

• เริ่มการประมูล

• ดำเนินการชำระเงิน

• ติดตามกิจกรรมของผู้ประมูล

จากการกระทำเหล่านี้ สถาปนิกสามารถสร้างชุด component เริ่มต้นสำหรับ GGG แล้วค่อย iterate ต่อได้ โซลูชันหนึ่งที่เป็นไปได้ปรากฏใน Figure 8-16

Figure 8-16. Initial set of components for Going, Going, Gone

ใน Figure 8-16 แต่ละบทบาทและการกระทำจะแม็ปไปยัง component หนึ่งตัว component เหล่านี้อาจต้องร่วมมือกันเพื่อแบ่งปันข้อมูล นี่คือ component ที่เราระบุไว้สำหรับโซลูชันนี้

Video Streamer

สตรีมการประมูลสดให้ผู้ใช้

Bid Streamer

สตรีมราคาประมูลให้ผู้ใช้เห็นทันทีที่เกิดขึ้น ทั้ง Video Streamer และ Bid Streamer มอบมุมมองแบบอ่านอย่างเดียว (read-only) ของการประมูลให้ผู้ประมูล

Bid Capture

component นี้เก็บราคาประมูลจากผู้ดำเนินการประมูลและผู้ประมูล

Bid Tracker

ติดตามราคาประมูลและทำหน้าที่เป็น system of record

Auction Session

เริ่มการประมูล เมื่อผู้ประมูลชนะและการประมูลสำหรับสินค้านั้นสิ้นสุดลง component นี้จะกระตุ้นขั้นตอนการชำระเงินและปิดการขาย รวมถึงแจ้งผู้ประมูลถึงสินค้าชิ้นถัดไปที่จะประมูล

Payment

ผู้ให้บริการประมวลผลการชำระเงินบุคคลที่สามสำหรับการชำระเงินด้วยบัตรเครดิต

หลังจากรอบแรกของการระบุ component (ดู Figure 8-6 ) สถาปนิกจะวิเคราะห์ architectural characteristics ที่ระบุไว้ก่อนหน้านี้ เพื่อตัดสินใจว่าจะมีตัวไหนที่เปลี่ยนแปลงการออกแบบ component หรือไม่ ตัวอย่างเช่น การออกแบบปัจจุบันมี component Bid Capture ที่เก็บราคาประมูลจากทั้งผู้ประมูลและผู้ดำเนินการประมูล สิ่งนี้สมเหตุสมผลในเชิงฟังก์ชัน คือ ราคาประมูลจากใครก็ตามสามารถเก็บและจัดการแบบเดียวกันได้ แต่ architectural characteristics ที่ระบุไว้ก่อนหน้านี้ต้องการอะไรจากการเก็บราคาประมูลบ้าง ผู้ดำเนินการประมูลไม่ต้องการ scalability หรือ elasticity ในระดับเดียวกับผู้ประมูล ซึ่งอาจมีจำนวนหลักพันคน

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

เพื่อรองรับระดับความต้องการที่แตกต่างกันของผู้ประมูลและผู้ดำเนินการประมูลสำหรับ architecture characteristics เดียวกัน สถาปนิกตัดสินใจแยก component Bid Capture ออกเป็นสอง component คือ Bid Capture และ Auctioneer Capture การออกแบบที่อัปเดตแล้วปรากฏใน Figure 8-17

สถาปนิกสร้าง component ใหม่สำหรับ Auctioneer Capture พวกเขายังอัปเดตลิงก์ข้อมูลจาก Auctioneer Capture ไปยังทั้ง Bid Streamer (เพื่อแสดงราคาประมูลสดให้ผู้ประมูลออนไลน์เห็น) และ Bid Tracker (เพื่อจัดการสตรีมราคาประมูล) Bid Tracker ตอนนี้กลายเป็น component ที่รวมสตรีมข้อมูลที่แตกต่างกันมากสองสายเข้าด้วยกัน คือสตรีมข้อมูลเดี่ยวจากผู้ดำเนินการประมูลและสตรีมหลายสายจากผู้ประมูล

Figure 8-17. Revised components of the GGG case study

การออกแบบที่แสดงใน Figure 8-17 ไม่น่าจะเป็นการออกแบบสุดท้าย ยังต้องค้นพบ requirement เพิ่มเติมอีก เช่น ผู้คนจะลงทะเบียนบัญชีใหม่อย่างไร ฟังก์ชันการชำระเงินจะถูกดูแลจัดการอย่างไร และอื่น ๆ อย่างไรก็ตาม การออกแบบนี้เป็นจุดเริ่มต้นที่ดีสำหรับการ iterate ต่อไป

นี่เป็นเพียงชุด component ที่เป็นไปได้ชุดหนึ่งสำหรับแก้ปัญหา GGG — แต่ไม่จำเป็นว่าจะต้องดีที่สุดหรือเป็นชุดเดียวที่ใช้ได้ มีระบบซอฟต์แวร์น้อยมากที่สามารถ implement ได้ด้วยวิธีเดียวเท่านั้น การออกแบบทุกแบบมี trade-off ชุดที่ต่างกัน ในฐานะสถาปนิก อย่าหมกมุ่นกับการหา "การออกแบบที่ถูกต้องเพียงหนึ่งเดียว" เพราะมีการออกแบบมากมายที่ใช้ได้ผลดีพอ พยายามประเมิน trade-off ระหว่างการตัดสินใจออกแบบต่าง ๆ อย่างเป็นภววิสัยที่สุดเท่าที่จะทำได้ แล้วเลือกแบบที่มีชุด trade-off ที่ "แย่น้อยที่สุด"