Decomposition by Layer (การแบ่งย่อยตามชั้น)

ทีนี้ คุณระบุ microservice ตัวแรกที่จะดึงออกมาแล้ว ต่อไปคืออะไร เราสามารถแบ่งการแบ่งย่อยนั้นออกเป็นขั้นตอนย่อย ๆ ต่อไปได้อีก

ถ้าเราพิจารณาสามชั้นดั้งเดิมของ stack บริการบนเว็บ เราก็สามารถดูฟังก์ชันการทำงานที่เราต้องการดึงออกในแง่ของ user interface, backend application code และข้อมูล

การ map จาก microservice ไปยัง user interface มักไม่ใช่แบบ 1:1 (นี่เป็นหัวข้อที่เราสำรวจในเชิงลึกมากขึ้นใน Chapter 14 ) ด้วยเหตุนี้ การดึงฟังก์ชันการทำงานด้าน user interface ที่เกี่ยวข้องกับ microservice นั้นอาจถือเป็นขั้นตอนแยกต่างหาก ผมขอเตือนตรงนี้เกี่ยวกับการเพิกเฉยต่อส่วน user interface ของสมการ ผมเคยเห็นหลายองค์กรเกินไปที่มองเฉพาะประโยชน์ของการแบ่งย่อยฟังก์ชันการทำงานฝั่ง backend เท่านั้น ซึ่งมักส่งผลให้เกิดแนวทางที่แยก silo มากเกินไปสำหรับการปรับโครงสร้างสถาปัตยกรรมใด ๆ บางครั้งประโยชน์ที่ใหญ่ที่สุดอาจมาจากการแบ่งย่อย UI ดังนั้นการเพิกเฉยเรื่องนี้จึงมีความเสี่ยง บ่อยครั้งการแบ่งย่อย UI มักตามหลังการแบ่งย่อย backend ให้เป็น microservices เพราะจนกว่า microservices จะพร้อมใช้งาน มันยากที่จะเห็นความเป็นไปได้สำหรับการแบ่งย่อย UI แค่อย่าปล่อยให้มันตามหลังมากเกินไป

ถ้าเรามองไปที่โค้ด backend และการจัดเก็บข้อมูลที่เกี่ยวข้อง สิ่งสำคัญคือทั้งสองอย่างต้องอยู่ในขอบเขตเมื่อดึง microservice ออกมา ลองพิจารณา Figure 3-2 ที่เรากำลังมองหาการดึงฟังก์ชันการทำงานที่เกี่ยวข้องกับการจัดการ wishlist ของลูกค้าออกมา มีโค้ดแอปพลิเคชันบางส่วนอยู่ใน monolith และมีการจัดเก็บข้อมูลที่เกี่ยวข้องอยู่ในฐานข้อมูล แล้วเราควรดึงส่วนไหนก่อน

Figure 3-2. โค้ดและข้อมูลของ wishlist ในแอปพลิเคชัน monolithic ที่มีอยู่

Code First (โค้ดก่อน)

ใน Figure 3-3 เราได้ดึงโค้ดที่เกี่ยวข้องกับฟังก์ชันการทำงานของ wishlist ออกมาเป็น microservice ใหม่ ข้อมูลของ wishlist ยังคงอยู่ในฐานข้อมูล monolithic ในขั้นตอนนี้ เรายังไม่เสร็จสิ้นการแบ่งย่อยจนกว่าเราจะย้ายข้อมูลที่เกี่ยวข้องกับ microservice Wishlist ใหม่ออกมาด้วยเช่นกัน

Figure 3-3. ย้ายโค้ดของ wishlist ไปยัง microservice ใหม่ก่อน โดยเหลือข้อมูลไว้ในฐานข้อมูล monolithic

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

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

Data First (ข้อมูลก่อน)

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

Figure 3-4. ตารางที่เกี่ยวข้องกับฟังก์ชันการทำงานของ wishlist ถูกดึงออกมาก่อน

ประโยชน์หลักของแนวทางนี้ในระยะสั้นคือการลดความเสี่ยงของการดึง microservice ออกมาแบบเต็มรูปแบบ มันบังคับให้คุณต้องจัดการกับปัญหาอย่างการสูญเสียการบังคับใช้ความสมบูรณ์ของข้อมูล (data integrity) ในฐานข้อมูลของคุณ หรือการขาด transactional operation ข้ามชุดข้อมูลทั้งสองชุดตั้งแต่เนิ่น ๆ เราจะแตะประเด็นเกี่ยวกับผลกระทบของทั้งสองปัญหานี้สั้น ๆ ในบทนี้ต่อไป