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

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

Figure 10-6. คะแนน characteristic ของ layered architecture

ต้นทุนโดยรวมและความเรียบง่ายเป็นจุดแข็งหลักของ layered architecture style เนื่องจากเป็น monolithic layered architecture จึงไม่ซับซ้อนเท่า distributed architecture style มันเรียบง่ายกว่า เข้าใจง่ายกว่า และมีต้นทุนในการสร้างและบำรุงรักษาที่ค่อนข้างต่ำ อย่างไรก็ตาม ควรระมัดระวัง เพราะคะแนนเหล่านี้จะลดลงอย่างรวดเร็วเมื่อ monolithic layered architecture มีขนาดใหญ่ขึ้นและซับซ้อนขึ้นตามไปด้วย

ทั้ง deployability และ testability ไม่ได้คะแนนดีนักสำหรับ architecture style นี้ Deployability ต่ำเพราะการ deploy มีความเสี่ยงสูง เกิดขึ้นไม่บ่อย และเกี่ยวข้องกับพิธีกรรมและความพยายามมากมาย ตัวอย่างเช่น การเปลี่ยนแปลง 3 บรรทัดง่าย ๆ ใน class file หนึ่งไฟล์ ก็ต้อง redeploy deployment unit ทั้งหมด ซึ่งเปิดโอกาสให้การเปลี่ยนแปลงในฐานข้อมูล configuration หรือแง่มุมอื่น ๆ ของโค้ดแอบแฝงเข้ามาพร้อมกับการเปลี่ยนแปลงเดิม ยิ่งไปกว่านั้น การเปลี่ยนแปลง 3 บรรทัดง่าย ๆ นี้มักจะถูกรวมเข้ากับการเปลี่ยนแปลงอื่น ๆ อีกหลายสิบรายการ ซึ่งแต่ละรายการก็ยิ่งเพิ่มความเสี่ยงและความถี่ของการ deploy คะแนน testability ที่ต่ำก็สะท้อนสถานการณ์นี้เช่นกัน สำหรับการเปลี่ยนแปลง 3 บรรทัดง่าย ๆ นักพัฒนาส่วนใหญ่จะไม่เสียเวลาหลายชั่วโมงรัน regression test suite ทั้งหมด (สมมติว่าพวกเขามี test suite แบบนั้นด้วยซ้ำ) เราให้คะแนน testability 2 ดาว (แทนที่จะเป็น 1 ดาว) เพราะ style นี้เปิดโอกาสให้ mock หรือ stub component หรือแม้แต่ทั้ง layer ได้ ซึ่งช่วยลดความยากในการทดสอบโดยรวม

คุณลักษณะทางวิศวกรรมของ layered architecture style สะท้อนพลวัตที่กล่าวไปข้างต้น กล่าวคือ ทุกอย่างเริ่มต้นได้ดี แต่จะแย่ลงเมื่อขนาดของโค้ดเบสเติบโตขึ้น

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

สถาปนิกสามารถทำให้ layered architecture มี responsiveness สูงได้ด้วยการออกแบบอย่างระมัดระวัง และเพิ่มขึ้นได้อีกด้วยเทคนิคอย่าง caching และ multithreading เราให้คะแนน style นี้ 3 ดาวโดยรวม เพราะมันยังคงประสบปัญหาจากการขาด parallel processing โดยธรรมชาติ รวมถึงจาก closed layering และ Architecture Sinkhole antipattern

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

layered architecture style เป็นตัวเลือกที่ดีสำหรับแอปพลิเคชันหรือเว็บไซต์ขนาดเล็กและเรียบง่าย มันยังเป็นจุดเริ่มต้นที่ดีสำหรับสถานการณ์ที่มีข้อจำกัดด้านงบประมาณและเวลาที่ตึงมาก เนื่องจากความเรียบง่ายและความคุ้นเคยของนักพัฒนาและสถาปนิก นี่อาจเป็นหนึ่งใน style ที่มีต้นทุนต่ำที่สุด ส่งเสริมความง่ายในการพัฒนาสำหรับแอปพลิเคชันขนาดเล็ก layered architecture style ยังเป็นตัวเลือกที่ดีเมื่อสถาปนิกยังตัดสินใจไม่ได้ว่า architecture ที่ซับซ้อนกว่าจะเหมาะสมกว่าหรือไม่ แต่ต้องเริ่มพัฒนาแล้ว

เมื่อใช้เทคนิคนี้ ควรรักษาการใช้โค้ดซ้ำให้น้อยที่สุด และรักษา object hierarchy (ความลึกของ inheritance tree) ให้ค่อนข้างตื้น เพื่อรักษาระดับ modularity ที่ดี สิ่งนี้จะช่วยให้การย้ายไปใช้ architecture style อื่นในภายหลังทำได้ง่ายขึ้น

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

ดังที่เราได้แสดงให้เห็นแล้ว คุณลักษณะอย่าง maintainability, agility, testability และ deployability จะได้รับผลกระทบในทางลบเมื่อแอปพลิเคชันที่ใช้ layered architecture style เติบโตขึ้น ด้วยเหตุนี้ แอปพลิเคชันและระบบขนาดใหญ่อาจเหมาะกับ architecture style อื่นที่มี modularity มากกว่า