Ownership Models (รูปแบบความเป็นเจ้าของ)

อย่างที่เราคุยกันไปแล้วใน Chapter 1 สถาปัตยกรรมแบบเลเยอร์ดั้งเดิมสามารถก่อให้เกิดปัญหาเมื่อพูดถึงการส่งมอบซอฟต์แวร์อย่างมีประสิทธิภาพ ใน Figure 14-1 เราจะเห็นตัวอย่างที่ความรับผิดชอบของเลเยอร์ส่วนติดต่อผู้ใช้เป็นของทีม frontend ทีมเดียว โดยงานฝั่ง backend service ทำโดยอีกทีมหนึ่ง ในตัวอย่างนี้ การเพิ่ม control ง่ายๆ เพียงอย่างเดียวต้องอาศัยงานจากสามทีมที่แตกต่างกัน โครงสร้างองค์กรแบบแบ่งชั้นเช่นนี้สามารถส่งผลกระทบอย่างมากต่อความเร็วในการส่งมอบของเรา เพราะต้องคอยประสานงานการเปลี่ยนแปลงและส่งต่องานระหว่างทีมอยู่ตลอดเวลา

Figure 14-1. การเปลี่ยนแปลงที่ต้องทำในทั้งสามเลเยอร์นั้นซับซ้อนกว่ามาก

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

ทีมที่เป็นเจ้าของ functionality แบบ end-to-end อย่างเต็มรูปแบบสามารถเปลี่ยนแปลงสิ่งต่างๆ ได้เร็วกว่า การมีความเป็นเจ้าของแบบเต็มรูปแบบยังกระตุ้นให้แต่ละทีมมีจุดติดต่อโดยตรงกับผู้ใช้ปลายทางของซอฟต์แวร์ด้วย สำหรับทีม backend แล้ว มันง่ายมากที่จะหลงลืมไปว่าใครคือผู้ใช้ปลายทางจริงๆ

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

Figure 14-2. UI ถูกแยกออกมาและเป็นของทีมที่ดูแล functionality ฝั่งเซิร์ฟเวอร์ที่รองรับ UI นั้นด้วย

Drivers for Dedicated Frontend Teams (แรงผลักดันสู่ทีม Frontend เฉพาะทาง)

ความต้องการทีม frontend เฉพาะทางดูเหมือนจะมาจากปัจจัยหลักสามอย่าง คือการขาดแคลนผู้เชี่ยวชาญ แรงผลักดันด้านความสม่ำเสมอ (consistency) และความท้าทายด้านเทคนิค

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

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

สุดท้าย เทคโนโลยี UI บางอย่างก็ทำงานด้วยได้ยากในรูปแบบที่ไม่ใช่ monolithic ตรงนี้ผมกำลังนึกถึง single-page application (SPA) โดยเฉพาะ ซึ่งในอดีตอย่างน้อยก็ไม่ใช่เรื่องง่ายที่จะแยกออกจากกัน แต่เดิม UI บนเว็บมักประกอบด้วยหลายหน้าเว็บ และคุณจะนำทางจากหน้าหนึ่งไปอีกหน้าหนึ่ง แต่สำหรับ SPA แอปพลิเคชันทั้งหมดจะถูกให้บริการอยู่ภายในหน้าเว็บเดียว เฟรมเวิร์กอย่าง Angular, React และ Vue ในทางทฤษฎีช่วยให้สร้างส่วนติดต่อผู้ใช้ที่ซับซ้อนกว่าเว็บไซต์แบบ "old-fashioned" ได้ เราจะมาดูชุดแพตเทิร์นที่ให้ตัวเลือกต่างๆ ในการแยกส่วนติดต่อผู้ใช้ในช่วงหลังของบทนี้ และในแง่ของ SPA ผมจะแสดงให้เห็นว่าแนวคิด micro frontend ช่วยให้คุณใช้เฟรมเวิร์ก SPA ได้ โดยไม่ต้องตกอยู่ในกับดักของ UI แบบ monolithic ได้อย่างไร