จากการแบ่งปันเรื่องของ Software Architecture ทั้ง Monolith, SOA และ Microservice นั้นคำถามที่เจอบ่อย ๆ คือ การจัดการให้ service หนึ่ง ๆ เป็น module/component ให้มันดีก่อนแต่เมื่อมีการติดต่อสื่อสารกันระหว่าง module แล้วจะจัดการ หรือ เลือกแนวทางไหนดีหนึ่งในแนวทางที่เคยอธิบายไว้แล้วคือ ผ่านตัวกลาง หรือ การติดต่อแบบ indect
ในการแบ่งปันเรื่อง Microservices design และ develop นั้นมักจะแนะนำเสมอว่า เริ่มจาก modular ให้มันดี ๆ ก่อน (process เดียวกัน)เริ่มด้วยการแบ่งการทำงานต่าง ๆ เป็น module หรือกลุ่มการทำงานก่อนจากนั้นดูการติดต่อสื่อสารระหว่าง module ว่าเป็นอย่างไร ?มันทำให้แต่ละ module ผูกมัดกันมากไปหรือไม่ ? (Tight coupling)
ต่อจากที่แนะนำ Spring Modulith ไปแล้วมาลองลงมือเขียน code ตามแนวทางนี้หน่อยว่าเป็นอย่างไรมีเครื่องมืออะไรที่น่าสนใจบ้าง
ตั้งแต่ JDK 9 ขึ้นมานั้น จะมี Java Linker มาให้ ซึ่งเป็น command line tool ช่วยให้เราสามารถทำการ custom JRE (Java Runtime Environment) เหมาะสมกับ application ของเราได้เอง โดยจะทำงานร่วมกับแนวคิดของ module นั่นเอง
จาก VDO เรื่อง Deconstructing the Monolith (Shopify Unite Track 2019) ทำการอธิบายถึง architecture ระบบของ Shopify ว่ามีความเป็นมาอย่างไร ตั้งแต่แบบ Monolith เมื่อระบบมีขนาดใหญ่และซับซ้อน จึงเกิดปัญหาและส่งผลกระทบต่อระบบ บริษัท รวมไปถึง productivity ในการพัฒนาระบบงาน ดังนั้นทาง Shopify จึงต้องทำการแก้ไขและปรับปรุงนั่นเอง
เขาบอกไว้ว่าคุณค่าจาก การออกแบบที่มันทดสอบได้ง่าย (Testable design) มันจะส่งผลให้ code ที่สร้างมานั้น ดีขึ้นกว่าเดิม ดังนั้น เรามาดูหน่อยกันหน่อยสิว่า Testable design มันเป็นอย่างไร รวมทั้งมีแนวคิดต่างๆ อย่างไร