Decision Criteria (เกณฑ์การตัดสินใจ)

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

ควรเข้าสู่ขั้นตอนการเลือกสถาปัตยกรรมสไตล์ก็ต่อเมื่อคุณมีความรู้เพียงพอเกี่ยวกับปัจจัยต่อไปนี้:

โดเมน (The domain)

ทำความเข้าใจแง่มุมสำคัญของโดเมนธุรกิจให้ได้มากที่สุดเท่าที่จะทำได้ โดยเฉพาะแง่มุมที่ส่งผลต่อคุณลักษณะสถาปัตยกรรม เชิงปฏิบัติการ สถาปนิกไม่จำเป็นต้องเป็นผู้เชี่ยวชาญในเรื่องนั้น แต่ควรเข้าใจภาพรวมของแง่มุมหลัก ๆ ของโดเมน ที่กำลังออกแบบ ผู้เชี่ยวชาญด้านอื่น เช่น business analyst สามารถช่วยเติมเต็มช่องว่างความรู้ด้านโดเมนของคุณได้

คุณลักษณะสถาปัตยกรรมที่ส่งผลต่อการตัดสินใจเชิงโครงสร้าง (Architecture characteristics that impact structural decisions)

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

เป็นไปได้ที่จะ implement สถาปัตยกรรมสไตล์ทั่วไปแทบทุกแบบในเกือบทุก problem domain— generic ก็หมายถึงการใช้งานได้ทั่วไปอยู่แล้ว ข้อยกเว้นคือโดเมนที่ต้องการคุณลักษณะสถาปัตยกรรมเชิงปฏิบัติการพิเศษ เช่น เว็บประมูลที่ต้อง scale ได้สูงมาก อย่างไรก็ตาม ในกรณีส่วนใหญ่ ความแตกต่างที่แท้จริงระหว่างสถาปัตยกรรมสไตล์ ไม่ได้อยู่ที่โดเมน แต่อยู่ที่แต่ละสไตล์รองรับคุณลักษณะสถาปัตยกรรมต่าง ๆ ได้ดีแค่ไหนต่างหาก

คุณอาจสังเกตเห็นว่า star chart ที่เราใช้ใน Part II ของหนังสือเล่มนี้เพื่อเปรียบเทียบแต่ละสถาปัตยกรรมสไตล์ โฟกัสที่ คุณลักษณะ ทางสถาปัตยกรรม ไม่ใช่โดเมน สิ่งนี้สะท้อนให้เห็นความสำคัญของการเข้าใจคุณลักษณะสถาปัตยกรรมเมื่อต้องเลือกสไตล์

สถาปัตยกรรมข้อมูล (Data architecture)

สถาปนิกและนักพัฒนาข้อมูลต้องร่วมมือกันเรื่องฐานข้อมูล schema และเรื่องอื่น ๆ ที่เกี่ยวกับข้อมูล สถาปัตยกรรมข้อมูลเป็นความเชี่ยวชาญเฉพาะทางในตัวมันเอง และเราไม่ได้ลงรายละเอียดมากนักในหนังสือเล่มนี้ นอกเหนือจากข้อพิจารณาเฉพาะสไตล์ อย่างไรก็ตาม คุณต้องเข้าใจผลกระทบที่การออกแบบข้อมูลหนึ่ง ๆ อาจมีต่อการออกแบบ สถาปัตยกรรมของคุณ โดยเฉพาะถ้าระบบใหม่ต้องทำงานร่วมกับสถาปัตยกรรมข้อมูลเก่าหรือที่ใช้งานอยู่แล้ว

การ deploy บนคลาวด์ (Cloud deployments)

การใช้คลาวด์เป็นปลายทางเชิงสถาปัตยกรรมคือการเปลี่ยนแปลงครั้งล่าสุดในสายของการเปลี่ยนแปลงพื้นฐานเกี่ยวกับที่ที่ การประมวลผลและข้อมูลอาศัยอยู่ trade-off ในการออกแบบแอปพลิเคชันให้รันบน on-premises นั้นแตกต่างอย่างมากจาก การออกแบบให้รันบนคลาวด์ สิ่งสำคัญคือต้องรู้ว่าแอปพลิเคชันจะต้องเก็บข้อมูลมากแค่ไหน และข้อมูลเคลื่อนย้ายได้มากแค่ไหน (ซึ่งอาจมีค่าใช้จ่ายสูงพอสมควร) รวมถึงข้อพิจารณาอื่น ๆ อีกมาก

คลาวด์เป็นตัวอย่างที่ดีของการที่ความสามารถซับซ้อนกลายเป็นสินค้าโภคภัณฑ์ (commodity) เมื่อเวลาผ่านไป เมื่อสิบปีก่อน การสร้างระบบ on-prem ที่ยืดหยุ่นและ scale ได้สูงต้องใช้ทักษะเฉพาะทางและถูกมองว่าแทบจะเป็นเรื่องมหัศจรรย์ แต่ตอนนี้ สถาปนิกสามารถได้ผลลัพธ์แบบเดียวกันได้แค่เปลี่ยน configuration ของผู้ให้บริการคลาวด์เท่านั้นเอง

ปัจจัยเชิงองค์กร (Organizational factors)

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

ความรู้เรื่องกระบวนการ ทีม และข้อพิจารณาด้านปฏิบัติการ (Knowledge of process, teams, and operational concerns)

ปัจจัยเฉพาะโปรเจกต์หลายอย่างส่งผลต่อการออกแบบของสถาปนิก ได้แก่ กระบวนการพัฒนาซอฟต์แวร์ การมีปฏิสัมพันธ์ (หรือไม่มี) ระหว่างสถาปนิกกับฝ่ายปฏิบัติการ และกระบวนการ QA ตัวอย่างเช่น หากองค์กรยังไม่มีวุฒิภาวะเพียงพอในแนวปฏิบัติ Agile สถาปัตยกรรมสไตล์ที่ต้องพึ่งพาแนวปฏิบัติเหล่านั้นเพื่อความสำเร็จ (เช่น microservices) จะเจอปัญหาได้ง่าย

Domain/architecture isomorphism (ไอโซมอร์ฟิซึมระหว่างโดเมนกับสถาปัตยกรรม)

Architecture isomorphism เป็นคำศัพท์ที่ดูหรูหราสำหรับ "รูปทรง" ทั่วไปของสถาปัตยกรรมหนึ่ง ๆ กล่าวอีกนัยหนึ่งคือ วิธีที่ component ต่าง ๆ พึ่งพากันภายในโทโพโลยีโดยรวม คำว่า isomorphism แปลว่า "การแมปที่รักษาเซตและความสัมพันธ์ระหว่างองค์ประกอบ" มันมาจากภาษากรีก isos ที่แปลว่า "เท่ากัน" และ morph ที่แปลว่า "รูปแบบ" หรือ "รูปทรง"

สถาปนิกคิดถึงรูปทรงทั่วไปของสถาปัตยกรรมเมื่อพิจารณาว่ามันเหมาะสมแค่ไหน ตัวอย่างเช่น ลองพิจารณาความแตกต่างระหว่าง ไดอะแกรม architecture isomorphism สองแบบสำหรับสถาปัตยกรรมสไตล์ layered monolith และ modular monolith ดังแสดงใน Figure 19-1 รูปทรงภายในของแต่ละสถาปัตยกรรมเห็นได้ชัดเจน คือการแยกตามเลเยอร์เทียบกับการแยกตามโดเมน

Figure 19-1. การเปรียบเทียบภาพแทนแบบ isomorphic ของ layered monolith และ modular monolith

ความแตกต่างระหว่าง monolithic และ distributed ก็ชัดเจนในลักษณะเดียวกันจากภาพวาด isomorphic ดังแสดงใน Figure 19-2 ในที่นี้ การกระจายตัวของ core component ทำให้เห็นโครงสร้างระดับมหภาคของสถาปัตยกรรมได้ชัดเจน

Figure 19-2. การเปรียบเทียบภาพแทนแบบ isomorphic ของสถาปัตยกรรมสไตล์ monolithic และ distributed

บาง problem domain เข้ากันได้ดีกับโทโพโลยีของสถาปัตยกรรม ตัวอย่างเช่น สถาปัตยกรรมสไตล์ microkernel เหมาะสมอย่างยิ่ง กับระบบที่ต้องการความสามารถในการปรับแต่ง (customizability)—สถาปนิกสามารถออกแบบการปรับแต่งเป็น plug-in ได้ อีกตัวอย่างหนึ่งคือ ระบบที่ออกแบบมาสำหรับการวิเคราะห์จีโนม ซึ่งต้องการการดำเนินการแบบแยกส่วนจำนวนมาก อาจเหมาะกับ space-based architecture ที่มี processor แบบแยกส่วนจำนวนมากให้ใช้

ในทำนองเดียวกัน บาง problem domain อาจไม่เหมาะกับสถาปัตยกรรมสไตล์บางแบบเลย ระบบที่ต้อง scale ได้สูงมักมีปัญหา กับการออกแบบแบบ monolithic ขนาดใหญ่ เพราะโค้ดที่ couple กันแน่นยากที่จะรองรับผู้ใช้พร้อมกันจำนวนมาก problem domain ที่มี semantic coupling สูงมากจะเข้ากันไม่ดีกับสถาปัตยกรรมแบบ distributed ที่ decouple สูง ตัวอย่างเช่น แอปพลิเคชันประกันภัยที่ประกอบด้วยฟอร์มหลายหน้า ซึ่งแต่ละหน้าอิงตามบริบทของหน้าก่อนหน้า ถือเป็นปัญหาที่ couple กันแน่นมาก การจำลองมันในสถาปัตยกรรมแบบ decoupled อย่าง microservices จะทำได้ยาก สถาปัตยกรรมที่ couple กันโดยตั้งใจ อย่าง service-based architecture จะเหมาะกับปัญหานี้มากกว่า

เมื่อคำนึงถึงทั้งหมดนี้แล้ว คุณต้องตัดสินใจหลายเรื่องในการเลือกสถาปัตยกรรมสไตล์:

Monolith หรือ distributed? (Monolith versus distributed?)

ชุดคุณลักษณะสถาปัตยกรรมชุดเดียวจะเพียงพอสำหรับการออกแบบหรือไม่ หรือส่วนต่าง ๆ ของระบบต้องการคุณลักษณะ สถาปัตยกรรมที่แตกต่างกัน ชุดเดียวบ่งบอกว่า monolith น่าจะเหมาะสม (แม้ปัจจัยอื่นอาจชี้ไปทาง distributed architecture) ส่วนชุดคุณลักษณะสถาปัตยกรรมที่แตกต่างกันบ่งบอกถึง distributed architecture แนวคิดเรื่อง architecture quantum ( Chapter 7 ) มีประโยชน์ในการตัดสินใจเรื่องนี้

ข้อมูลควรอยู่ที่ไหน? (Where should data live?)

หากสถาปัตยกรรมเป็นแบบ monolithic สถาปนิกมักสันนิษฐานว่าจะใช้ relational database เดียว หรืออาจจะไม่กี่ตัว ในสถาปัตยกรรมแบบ distributed คุณต้องตัดสินใจว่า service ไหนควร persist ข้อมูล ซึ่งก็หมายถึงต้องคิดด้วยว่า ข้อมูลจะไหลผ่านสถาปัตยกรรมอย่างไรเพื่อสร้าง workflow พิจารณาทั้งโครงสร้างและพฤติกรรมเมื่อออกแบบสถาปัตยกรรม และอย่ากลัวที่จะทำซ้ำการออกแบบเพื่อหาชุดผสมที่ดีกว่า

Service ควรสื่อสารแบบ synchronous หรือ asynchronous? (Should services communicate synchronously or asynchronously?)

เมื่อคุณตัดสินใจแล้วว่าข้อมูลควรอยู่ที่ไหน ขั้นต่อไปที่ต้องพิจารณาในการออกแบบคือการสื่อสารระหว่าง service— ควรเป็น synchronous หรือ asynchronous การสื่อสารแบบ synchronous มักสะดวกกว่า แต่อาจต้องแลกกับ scalability, reliability และคุณลักษณะอื่น ๆ ที่ต้องการ การสื่อสารแบบ asynchronous ให้ประโยชน์เฉพาะตัวในแง่ performance และ scale แต่ก็มาพร้อมความปวดหัวมากมายเรื่อง data synchronization, deadlock, race condition, การ debug และอื่น ๆ (เราครอบคลุมประเด็นเหล่านี้ส่วนใหญ่ไว้ใน Chapter 15 )

เนื่องจากการสื่อสารแบบ synchronous มีความท้าทายด้านการออกแบบ การ implement และการ debug น้อยกว่า เราแนะนำให้ใช้ synchronous เป็นค่าเริ่มต้นเมื่อทำได้ และใช้ asynchronous เฉพาะเมื่อจำเป็นเท่านั้น

Tip (เคล็ดลับ)

ใช้การสื่อสารแบบ synchronous เป็นค่าเริ่มต้น และใช้ asynchronous เมื่อจำเป็นเท่านั้น

ผลลัพธ์ของกระบวนการออกแบบนี้คือ architecture topology ที่ครอบคลุมสถาปัตยกรรมสไตล์ที่เลือก (และการผสมผสานสไตล์ใด ๆ), Architectural Decision Records (ADR) เกี่ยวกับส่วนของการออกแบบที่ต้องใช้ความพยายามมากที่สุด และ architecture fitness function เพื่อปกป้องหลักการสำคัญ และคุณลักษณะสถาปัตยกรรมเชิงปฏิบัติการ