Style Characteristics (คุณลักษณะของสไตล์)

คะแนน 1 ดาวในตาราง characteristic rating Figure 11-7 หมายความว่า architecture characteristic นั้นไม่ได้รับการรองรับที่ดีนักใน architecture ในขณะที่คะแนน 5 ดาว หมายความว่า architecture characteristic นั้นเป็นหนึ่งในจุดแข็งที่สุดของ architecture style นี้ characteristic ที่มีอยู่ใน scorecard ถูกอธิบายและนิยามไว้ใน Chapter 4 .

modular monolith architecture style เป็น architecture แบบ domain-partitioned เพราะ application logic ของมันถูกแบ่งพาร์ทิชันเป็น module เนื่องจากมันมักถูก implement เป็น monolithic deployment architectural quantum ของมันจึงมักจะเท่ากับ 1

ต้นทุนโดยรวม ความเรียบง่าย และ modularity เป็นจุดแข็งหลักของ modular monolith architecture style เนื่องจากเป็น monolithic โดยธรรมชาติ architecture เหล่านี้จึงไม่มีความซับซ้อนที่เกี่ยวข้องกับ distributed architecture style มันเรียบง่ายกว่าและเข้าใจง่ายกว่า และมีต้นทุนในการสร้างและบำรุงรักษาที่ค่อนข้างต่ำ architectural modularity เกิดขึ้นได้จากการแยก concern ระหว่าง module ต่าง ๆ ซึ่งแทน domain และ subdomain

Deployability และ testability แม้จะได้แค่ 2 ดาว แต่ก็ได้คะแนนสูงกว่า layered architecture เล็กน้อยใน modular monolith เนื่องจากระดับ modularity ของมัน กระนั้นก็ตาม architecture style นี้ก็ยังคงเป็น monolith อยู่ดี ดังนั้นพิธีกรรม ความเสี่ยง ความถี่ในการ deploy และความครบถ้วนของการทดสอบจึงส่งผลกระทบในทางลบต่อคะแนนเหล่านี้

Elasticity และ scalability ของ modular monolith architecture ได้คะแนนต่ำมาก (1 ดาว) ส่วนใหญ่เป็นเพราะการ deploy แบบ monolithic แม้ว่าจะเป็นไปได้ที่จะทำให้ฟังก์ชันบางอย่างภายใน monolith scale ได้มากกว่าฟังก์ชันอื่น แต่ความพยายามนี้มักต้องใช้เทคนิคการออกแบบที่ซับซ้อนมาก (เช่น multithreading, internal messaging และแนวปฏิบัติการประมวลผลแบบขนานอื่น ๆ) ซึ่ง architecture นี้ไม่เหมาะสมนัก

Figure 11-7. คะแนน star rating ของ architectural characteristic สำหรับ modular monolith

modular monolith architecture ที่ deploy แบบ monolithic ไม่รองรับ fault tolerance ถ้าส่วนเล็ก ๆ ส่วนหนึ่งของ architecture ทำให้เกิดสภาวะหน่วยความจำไม่พอ แอปพลิเคชันทั้งหน่วยจะล่มไปด้วย ยิ่งไปกว่านั้น เช่นเดียวกับแอปพลิเคชัน monolithic ส่วนใหญ่ availability โดยรวมได้รับผลกระทบจาก mean time to recovery (MTTR) ที่สูง โดยเวลา startup มักวัดกันเป็นนาที

When to Use (เมื่อใดควรใช้)

เนื่องจากความเรียบง่ายและต้นทุนต่ำ modular monolith architecture style เป็นตัวเลือกที่ดีเมื่อเผชิญกับข้อจำกัดด้านงบประมาณและเวลาที่ตึง มันยังเป็นตัวเลือกที่ดีสำหรับการเริ่มต้นระบบใหม่ ถ้าทิศทาง architecture ของระบบยังไม่ชัดเจน มักจะมีประสิทธิภาพมากกว่าที่จะเริ่มต้นด้วย modular monolith แล้วค่อยย้ายไปใช้ distributed architecture style ที่ซับซ้อนและมีราคาแพงกว่าในภายหลัง เช่น service based (ดู Chapter 14 ) หรือ microservices (ดู Chapter 18 ) มากกว่าที่จะกระโดดเข้าสู่ distributed architecture ตั้งแต่แรก

modular monolith ยังเป็นตัวเลือกที่ดีสำหรับทีมที่เน้น domain เช่น cross-functional team ที่มีความเชี่ยวชาญเฉพาะทาง สิ่งนี้ทำให้แต่ละทีมสามารถมุ่งเน้นไปที่ module เฉพาะภายใน architecture ตั้งแต่ต้นจนจบ โดยมีการประสานงานกับทีม domain อื่นน้อยที่สุด architectural style นี้ยังเหมาะกับสถานการณ์ที่การเปลี่ยนแปลงส่วนใหญ่ในระบบอิงตาม domain (เช่น การเพิ่มวันหมดอายุให้กับสินค้าใน wishlist ของลูกค้า)

สุดท้ายนี้ เนื่องจาก modular monolith เป็น domain-partitioned architecture มันจึงเหมาะสมกับทีมที่ทำงานแบบ DDD .

When Not to Use (เมื่อใดไม่ควรใช้)

เหตุผลหลักที่ไม่ควรใช้ architectural style นี้คือเมื่อระบบหรือผลิตภัณฑ์ต้องการ operational characteristic ในระดับสูง เช่น scalability, elasticity, availability, fault tolerance, responsiveness และ performance เช่นเดียวกับ monolithic architecture ส่วนใหญ่ modular monolith ไม่เหมาะกับ architectural concern เหล่านี้

หลีกเลี่ยงการใช้ modular monolith เมื่อการเปลี่ยนแปลงส่วนใหญ่มุ่งเน้นไปทางเทคนิค เช่น การเปลี่ยน user interface หรือเทคโนโลยีฐานข้อมูลอยู่เรื่อย ๆ เนื่องจาก architecture นี้ถูกแบ่งพาร์ทิชันตาม domain การเปลี่ยนแปลงแบบนี้จะส่งผลกระทบต่อทุก module และมักต้องการการสื่อสารและการประสานงานอย่างมากระหว่างทีม domain ในสถานการณ์เช่นนี้ layered architecture style (ดู Chapter 10 ) เป็นตัวเลือกที่ดีกว่ามาก