Common Risks (ความเสี่ยงที่พบได้ทั่วไป)

เช่นเดียวกับระบบ monolithic ใด ๆ ความเสี่ยงหลักของ modular monolith architectural style คือมันอาจใหญ่เกินไปจนบำรุงรักษา ทดสอบ และ deploy ได้อย่างเหมาะสม monolithic architecture ในตัวมันเองไม่ใช่สิ่งที่แย่ แต่ปัญหาจะเริ่มเกิดขึ้นเมื่อมันใหญ่เกินไป คำว่า “ใหญ่เกินไป” หมายถึงอะไรนั้นแตกต่างกันไปในแต่ละระบบ แต่นี่คือสัญญาณเตือนบางอย่างที่บอกว่าระบบอาจใหญ่เกินไป:

• การเปลี่ยนแปลงใช้เวลานานเกินไป

• เมื่อพื้นที่หนึ่งของระบบถูกเปลี่ยนแปลง พื้นที่อื่น ๆ กลับพังโดยไม่คาดคิด

• สมาชิกในทีมขวางทางกันเองเมื่อทำการเปลี่ยนแปลง

• ระบบใช้เวลา startup นานเกินไป

ความเสี่ยงอีกอย่างหนึ่งคือการใช้โค้ดซ้ำมากเกินไป การใช้โค้ดซ้ำและการแชร์โค้ดเป็นส่วนที่จำเป็นของการพัฒนาซอฟต์แวร์ แต่ใน architecture style นี้ การใช้โค้ดซ้ำมากเกินไปจะทำให้ขอบเขตของ module เบลอ นำ architecture ไปสู่พื้นที่เสี่ยงของ unstructured monolith : monolithic architecture ที่มีโค้ดพึ่งพากันสูงมากจนไม่สามารถแกะออกจากกันได้

การสื่อสารระหว่าง module มากเกินไปก็เป็นอีกความเสี่ยงหนึ่งใน architectural style นี้ โดยหลักการแล้ว module ควรเป็นอิสระและจบในตัวเอง ดังที่เราได้กล่าวไปแล้วว่า เป็นเรื่องปกติ (และบางครั้งก็จำเป็น) ที่บาง module จะต้องสื่อสารกับ module อื่น โดยเฉพาะใน workflow ที่ซับซ้อน อย่างไรก็ตาม ถ้ามีการสื่อสารระหว่าง module มากเกินไป นั่นเป็นสัญญาณที่ดีว่า domain อาจถูกนิยามไว้ไม่ดีตั้งแต่แรก ในกรณีเช่นนี้ ควรพิจารณาให้มากขึ้นในการนิยาม domain ใหม่ เพื่อรองรับ workflow ที่ซับซ้อนและความพึ่งพากัน