คู่มือสถาปัตยกรรมแอป

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

การจัดวางองค์ประกอบของแอป

โดยทั่วไปแล้ว แอป Android ประกอบด้วยคอมโพเนนต์ของแอปหลายรายการ เช่น บริการ ผู้ให้บริการเนื้อหา และตัวรับสัญญาณ การออกอากาศ คุณประกาศคอมโพเนนต์เหล่านี้ในไฟล์ Manifest ของแอป

อินเทอร์เฟซผู้ใช้ของแอปก็เป็นคอมโพเนนต์เช่นกัน ในอดีต UI สร้างขึ้นโดยใช้กิจกรรมหลายรายการ อย่างไรก็ตาม แอปสมัยใหม่ใช้ สถาปัตยกรรมแบบกิจกรรมเดียว Activity เดียวจะทำหน้าที่เป็นคอนเทนเนอร์สำหรับหน้าจอที่ใช้เป็นFragment หรือปลายทาง Jetpack Compose

รูปแบบของอุปกรณ์ที่หลากหลาย

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

ข้อจำกัดของทรัพยากร

อุปกรณ์เคลื่อนที่ แม้จะเป็นอุปกรณ์ที่มีหน้าจอขนาดใหญ่ก็มีข้อจำกัดด้านทรัพยากร ดังนั้นระบบปฏิบัติการอาจหยุดกระบวนการของแอปบางอย่างได้ทุกเมื่อเพื่อ เปิดพื้นที่สำหรับกระบวนการใหม่

เงื่อนไขการเปิดตัวแบบแปรผัน

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

หลักการสถาปัตยกรรมที่พบบ่อย

หากใช้คอมโพเนนต์ของแอปเพื่อจัดเก็บข้อมูลและสถานะของแอปพลิเคชันไม่ได้ คุณควรออกแบบแอปอย่างไร

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

การแยกความกังวล

ออกแบบสถาปัตยกรรมของแอปให้เป็นไปตามหลักการที่เฉพาะเจาะจง 2-3 ข้อ

หลักการที่สำคัญที่สุดคือการแยกความกังวล การเขียนโค้ดทั้งหมดใน Activity หรือ Fragment เป็น ข้อผิดพลาดที่พบบ่อย

บทบาทหลักของ Activity หรือ Fragment คือการโฮสต์ UI ของแอป ระบบปฏิบัติการ Android จะควบคุมวงจรของ Fragment โดยมักจะทำลายและสร้าง Fragment ใหม่ เพื่อตอบสนองต่อการกระทำของผู้ใช้ เช่น การหมุนหน้าจอ หรือเหตุการณ์ของระบบ เช่น หน่วยความจำเหลือน้อย

ลักษณะชั่วคราวนี้ทําให้ไม่เหมาะสําหรับการจัดเก็บข้อมูลหรือสถานะของแอปพลิเคชัน หากคุณจัดเก็บข้อมูลใน Activity หรือ Fragment ข้อมูลนั้นจะหายไปเมื่อ สร้างคอมโพเนนต์ขึ้นมาใหม่ อย่าฝากสถานะไว้กับคอมโพเนนต์ UI เหล่านี้เพื่อให้มั่นใจว่าข้อมูลจะยังคงอยู่และมอบประสบการณ์การใช้งานที่เสถียรแก่ผู้ใช้

เลย์เอาต์แบบปรับขนาดได้

แอปควรจัดการการเปลี่ยนแปลงการกำหนดค่าอย่างเหมาะสม เช่น การเปลี่ยนแปลงการวางแนวของอุปกรณ์หรือการเปลี่ยนแปลงขนาดหน้าต่างแอป ใช้เลย์เอาต์มาตรฐานแบบปรับได้เพื่อมอบประสบการณ์การใช้งานที่ดีที่สุดในอุปกรณ์รูปแบบต่างๆ

ขับเคลื่อน UI จากโมเดลข้อมูล

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

โมเดลแบบถาวรเหมาะสำหรับกรณีต่อไปนี้

• ผู้ใช้จะไม่สูญเสียข้อมูลหากระบบปฏิบัติการ Android ทำลายแอปเพื่อเพิ่มพื้นที่ว่าง ให้กับทรัพยากร

• แอปจะทำงานต่อไปในกรณีที่การเชื่อมต่อเครือข่าย ขาดตอนหรือใช้งานไม่ได้

สร้างสถาปัตยกรรมแอปตามคลาสโมเดลข้อมูลเพื่อให้แอปมีประสิทธิภาพและ ทดสอบได้

แหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียว

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

รูปแบบนี้มีประโยชน์หลายประการ ดังนี้

• รวมการเปลี่ยนแปลงทั้งหมดของข้อมูลประเภทหนึ่งๆ ไว้ในที่เดียว
• ปกป้องข้อมูลเพื่อไม่ให้ข้อมูลประเภทอื่นแก้ไขได้
• ทำให้การเปลี่ยนแปลงข้อมูลติดตามได้ง่ายขึ้น จึงทำให้พบข้อบกพร่องได้ง่ายขึ้น

ในแอปพลิเคชันที่ทำงานแบบออฟไลน์เป็นอันดับแรก แหล่งข้อมูลที่เชื่อถือได้สำหรับข้อมูลแอปพลิเคชันมักจะเป็นฐานข้อมูล ในกรณีอื่นๆ แหล่งข้อมูลที่เชื่อถือได้อาจเป็นViewModel

การไหลของข้อมูลแบบทางเดียว

โดยมักจะใช้หลักการแหล่งข้อมูลที่ถูกต้องแห่งเดียว ร่วมกับรูปแบบการไหลของข้อมูลแบบทิศทางเดียว (UDF) ใน UDF state จะไหลไปในทิศทางเดียว โดยปกติจะไหลจากคอมโพเนนต์หลักไปยังคอมโพเนนต์ย่อย เหตุการณ์ ที่แก้ไขการไหลของข้อมูลในทิศทางตรงกันข้าม

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

รูปแบบนี้ช่วยรักษาความสอดคล้องของข้อมูลได้ดีขึ้น มีแนวโน้มที่จะเกิดข้อผิดพลาดน้อยกว่า ดีบักได้ง่ายกว่า และให้ประโยชน์ทั้งหมดของรูปแบบ SSOT

สถาปัตยกรรมของแอปที่แนะนำ

เมื่อพิจารณาหลักการทางสถาปัตยกรรมทั่วไปแล้ว แต่ละแอปพลิเคชันควรมีเลเยอร์อย่างน้อย 2 เลเยอร์ ดังนี้

• เลเยอร์ UI: แสดงข้อมูลแอปพลิเคชันบนหน้าจอ
• เลเยอร์ข้อมูล: มีตรรกะทางธุรกิจของแอปและแสดงข้อมูลแอปพลิเคชัน

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

สถาปัตยกรรมแอปสมัยใหม่

สถาปัตยกรรมแอป Android สมัยใหม่ใช้เทคนิคต่อไปนี้ (รวมถึงเทคนิคอื่นๆ)

• สถาปัตยกรรมแบบปรับเปลี่ยนได้และแบบเลเยอร์
• การไหลของข้อมูลแบบทางเดียว (UDF) ในทุกเลเยอร์ของแอป
• เลเยอร์ UI ที่มีตัวเก็บสถานะเพื่อจัดการความซับซ้อนของ UI
• โครูทีนและโฟลว์
• แนวทางปฏิบัติแนะนำสำหรับการแทรกการอ้างอิง

ดูข้อมูลเพิ่มเติมได้ที่คำแนะนำสำหรับสถาปัตยกรรม Android

เลเยอร์ UI

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

เลเยอร์ UI ประกอบด้วยโครงสร้าง 2 ประเภท ได้แก่

• องค์ประกอบ UI ที่แสดงข้อมูลบนหน้าจอ คุณสร้างองค์ประกอบเหล่านี้ โดยใช้ฟังก์ชัน Jetpack Compose เพื่อรองรับเลย์เอาต์ที่ปรับเปลี่ยนได้
• ตัวเก็บสถานะ (เช่น ViewModel) ที่เก็บข้อมูล แสดงข้อมูล ต่อ UI และจัดการตรรกะ

สำหรับ UI ที่ปรับเปลี่ยนตามอุปกรณ์ ตัวยึดสถานะ เช่น ออบเจ็กต์ ViewModel จะแสดงสถานะ UI ที่ ปรับให้เข้ากับคลาสขนาดหน้าต่างต่างๆ คุณใช้ currentWindowAdaptiveInfo() เพื่อสร้างสถานะ UI นี้ได้ จากนั้นคอมโพเนนต์ต่างๆ เช่น NavigationSuiteScaffold จะใช้ข้อมูลนี้เพื่อสลับ ระหว่างรูปแบบการนำทางต่างๆ (เช่น NavigationBar NavigationRail หรือ NavigationDrawer) โดยอัตโนมัติตามพื้นที่หน้าจอที่มี

ดูข้อมูลเพิ่มเติมได้ที่หน้าเลเยอร์ UI

ชั้นข้อมูล

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

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

คลาสที่เก็บมีหน้าที่รับผิดชอบในเรื่องต่อไปนี้

• การเปิดเผยข้อมูลต่อส่วนอื่นๆ ของแอป
• รวมการเปลี่ยนแปลงข้อมูลไว้ที่เดียว
• การแก้ไขความขัดแย้งระหว่างแหล่งข้อมูลหลายแหล่ง
• แยกแหล่งข้อมูลออกจากส่วนอื่นๆ ของแอป
• มีตรรกะทางธุรกิจ

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

ดูข้อมูลเพิ่มเติมได้ที่หน้า Data Layer

เลเยอร์โดเมน

เลเยอร์โดเมนเป็นเลเยอร์ที่ไม่บังคับระหว่างเลเยอร์ UI กับเลเยอร์ข้อมูล

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

โดยทั่วไปแล้ว คลาสในเลเยอร์โดเมนเรียกว่า Use Case หรือ Interactor แต่ละกรณีการใช้งานควรรับผิดชอบฟังก์ชันการทำงานเดียว ตัวอย่างเช่น แอปของคุณอาจมีGetTimeZoneUseCaseคลาสหาก View Model หลายรายการต้องอาศัยเขตเวลาเพื่อแสดงข้อความที่เหมาะสมบนหน้าจอ

ดูข้อมูลเพิ่มเติมได้ที่หน้าเลเยอร์โดเมน

จัดการการขึ้นต่อกันระหว่างคอมโพเนนต์

คลาสในแอปของคุณต้องอาศัยคลาสอื่นๆ เพื่อให้ทำงานได้อย่างถูกต้อง คุณสามารถใช้รูปแบบการออกแบบต่อไปนี้เพื่อรวบรวมการอ้างอิงของคลาสหนึ่งๆ ได้

• การแทรกการอ้างอิง (DI): การแทรกการอ้างอิงช่วยให้คลาสกำหนดการอ้างอิงได้โดยไม่ต้องสร้างการอ้างอิงเหล่านั้น ในเวลาเรียกใช้ คลาสอื่น มีหน้าที่จัดเตรียมทรัพยากร Dependency เหล่านี้
• ตัวระบุตำแหน่งบริการ: รูปแบบตัวระบุตำแหน่งบริการ มีรีจิสทรีที่คลาสสามารถรับทรัพยากร Dependency แทนการสร้างได้

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

แนวทางปฏิบัติแนะนำโดยทั่วไป

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

แม้ว่าคำแนะนำต่อไปนี้จะไม่บังคับ แต่ในกรณีส่วนใหญ่ การทำตามคำแนะนำจะช่วยให้โค้ดเบสมีความแข็งแกร่ง ทดสอบได้ และบำรุงรักษาได้มากขึ้น

อย่าจัดเก็บข้อมูลในคอมโพเนนต์ของแอป

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

ลดการพึ่งพาคลาส Android

คอมโพเนนต์ของแอปควรเป็นคลาสเดียวที่ใช้ API ของ Android Framework SDK เช่น Context หรือ Toast การแยกคลาสอื่นๆ ในแอปออกจากคอมโพเนนต์ของแอปจะช่วยให้ทดสอบได้ง่ายขึ้นและลดการเชื่อมโยงภายในแอป

กำหนดขอบเขตความรับผิดชอบที่ชัดเจนระหว่างโมดูลในแอป

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

เปิดเผยข้อมูลจากแต่ละโมดูลให้น้อยที่สุด

อย่าสร้างทางลัดที่เปิดเผยรายละเอียดการใช้งานภายใน คุณอาจประหยัดเวลาได้เล็กน้อยในระยะสั้น แต่มีแนวโน้มที่จะก่อให้เกิดหนี้ทางเทคนิคหลายครั้งเมื่อโค้ดเบสมีการพัฒนา

มุ่งเน้นที่แกนหลักที่เป็นเอกลักษณ์ของแอปเพื่อให้แอปโดดเด่นจากแอปอื่นๆ

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

ใช้เลย์เอาต์มาตรฐานและรูปแบบการออกแบบแอป

ไลบรารี Jetpack Compose มี API ที่มีประสิทธิภาพสำหรับการสร้างอินเทอร์เฟซผู้ใช้ที่ปรับเปลี่ยนได้ ใช้เลย์เอาต์มาตรฐานในแอปเพื่อ เพิ่มประสิทธิภาพประสบการณ์ของผู้ใช้ในอุปกรณ์หลากหลายรูปแบบและขนาดการแสดงผล ดูแกลเลอรีรูปแบบการออกแบบแอปเพื่อเลือกเลย์เอาต์ที่เหมาะกับกรณีการใช้งานของคุณมากที่สุด

คงสถานะ UI ไว้เมื่อมีการเปลี่ยนแปลงการกำหนดค่า

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

ออกแบบคอมโพเนนต์ UI ที่นำกลับมาใช้ใหม่และประกอบกันได้

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

พิจารณาวิธีทำให้แต่ละส่วนของแอปทดสอบได้แยกกัน

API ที่กำหนดไว้อย่างดีสำหรับการดึงข้อมูลจากเครือข่ายจะช่วยอำนวยความสะดวกในการทดสอบโมดูลที่จัดเก็บข้อมูลนั้นไว้ในฐานข้อมูลในเครื่อง ในทางกลับกัน หากคุณรวมตรรกะจากฟังก์ชันทั้ง 2 นี้ไว้ในที่เดียว หรือกระจายโค้ดเครือข่ายไปทั่วทั้งโค้ดเบส การทดสอบจะยากขึ้นมาก หรืออาจเป็นไปไม่ได้เลย

ประเภทมีหน้าที่รับผิดชอบต่อนโยบายการทำงานพร้อมกัน

หากประเภทใดกำลังทำงานที่บล็อกเป็นเวลานาน ประเภทนั้นควร รับผิดชอบในการย้ายการคำนวณดังกล่าวไปยังเธรดที่เหมาะสม ประเภทจะทราบ การคำนวณที่กำลังทำอยู่และเธรดที่ควร ดำเนินการคำนวณ ประเภทควรเป็นแบบ main-safe ซึ่งหมายความว่าเรียกใช้จากเทรดหลักได้อย่างปลอดภัยโดยไม่บล็อก

เก็บข้อมูลที่เกี่ยวข้องและเป็นปัจจุบันให้ได้มากที่สุด

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

ประโยชน์ของสถาปัตยกรรม

การใช้สถาปัตยกรรมที่ดีในแอปจะช่วยให้ทีมวิศวกรรมและทีมโปรเจ็กต์ได้รับประโยชน์มากมาย ดังนี้

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

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

ตัวอย่าง

ตัวอย่างต่อไปนี้แสดงสถาปัตยกรรมแอปที่ดี