Topology

Component ต่าง ๆ ภายใน layered architecture style จะถูกจัดระเบียบเป็น layer แนวนอนเชิงตรรกะ ดังที่แสดงใน Figure 10-1 โดยแต่ละ layer ทำหน้าที่เฉพาะภายในแอปพลิเคชัน (เช่น presentation logic หรือ business logic) แม้ว่าจะไม่มีข้อจำกัดเฉพาะเจาะจงในแง่ของจำนวนและประเภทของ layer ที่ต้องมี แต่ layered architecture ส่วนใหญ่จะประกอบด้วย 4 layer มาตรฐาน ได้แก่ Presentation, Business, Persistence และ Database บาง architecture รวม Business layer กับ Persistence layer เข้าด้วยกัน โดยเฉพาะอย่างยิ่งเมื่อ persistence logic (เช่น SQL หรือ HSQL) ถูกฝังอยู่ภายใน component ของ Business layer แอปพลิเคชันขนาดเล็กอาจมีเพียง 3 layer ในขณะที่แอปพลิเคชันธุรกิจขนาดใหญ่และซับซ้อนกว่าอาจมี 5 layer หรือมากกว่านั้น

Standard logical layers

Figure 10-1. layer เชิงตรรกะมาตรฐานภายใน layered architecture style

Figure 10-2 แสดงรูปแบบ topology หลากหลายแบบจากมุมมองของ physical layering (การ deploy) รูปแบบแรกรวม Presentation, Business และ Persistence layer เข้าไว้ใน deployment unit เดียว โดย Database layer มักจะแสดงเป็นฐานข้อมูล physical ภายนอกที่แยกต่างหาก (หรือ filesystem) รูปแบบที่สองแยก Presentation layer ออกเป็น deployment unit ของตัวเองในทาง physical โดย Business layer และ Persistence layer รวมกันเป็น deployment unit ที่สอง เช่นเดียวกับรูปแบบนี้ Database layer มักจะถูกแยกออกในทาง physical ผ่านฐานข้อมูลภายนอกหรือ filesystem รูปแบบที่สามรวม layer มาตรฐานทั้ง 4 เข้าไว้ใน deployment เดียว รวมถึง Database layer ด้วย รูปแบบนี้อาจมีประโยชน์สำหรับแอปพลิเคชันขนาดเล็กที่มีฐานข้อมูลฝังตัวภายในหรือฐานข้อมูลแบบ in-memory เช่น แอปพลิเคชันบนอุปกรณ์มือถือ ผลิตภัณฑ์แบบ on-premises (on-prem) จำนวนมากถูกสร้างและส่งมอบให้ลูกค้าโดยใช้รูปแบบที่สามนี้

Physical topology variants

Figure 10-2. รูปแบบ physical topology (การ deploy) ที่หลากหลาย

แต่ละ layer มีบทบาทและความรับผิดชอบเฉพาะเจาะจง และสร้าง abstraction รอบ ๆ งานที่ต้องทำเพื่อตอบสนอง business request หนึ่ง ๆ ตัวอย่างเช่น Presentation layer รับผิดชอบการจัดการ UI และ logic การสื่อสารกับ browser ทั้งหมด ในขณะที่ Business layer รับผิดชอบการรัน business rule เฉพาะที่เกี่ยวข้องกับ request นั้น Presentation layer ไม่จำเป็นต้องรู้หรือกังวลว่าจะดึงข้อมูลลูกค้ามาอย่างไร มันแค่ต้องแสดงข้อมูลนั้นบนหน้าจอในรูปแบบที่กำหนด ในทำนองเดียวกัน Business layer ไม่จำเป็นต้องกังวลว่าจะจัดรูปแบบข้อมูลลูกค้าเพื่อแสดงบนหน้าจออย่างไร หรือแม้แต่ข้อมูลนั้นมาจากไหน มันแค่ต้องดึงข้อมูลจาก Persistence layer รัน business logic กับมัน (เช่น การคำนวณค่าหรือการรวมข้อมูล) แล้วส่งข้อมูลนั้นขึ้นไปให้ Presentation layer

การแยก concern แบบนี้ภายใน layered architecture style ทำให้สร้าง role และ responsibility model ที่มีประสิทธิภาพได้ง่าย component ภายใน layer หนึ่ง ๆ จะมีขอบเขตจำกัด โดยจัดการเฉพาะ logic ที่เกี่ยวข้องกับ layer นั้นเท่านั้น ตัวอย่างเช่น component ใน Presentation layer จะจัดการเฉพาะ presentation logic ในขณะที่ component ที่อยู่ใน Business layer จะจัดการเฉพาะ business logic เท่านั้น สิ่งนี้ทำให้นักพัฒนาสามารถใช้ความเชี่ยวชาญเชิงเทคนิคเฉพาะของตนมุ่งเน้นไปที่แง่มุมทางเทคนิคของ domain นั้น ๆ (เช่น presentation logic หรือ persistence logic) แต่ trade-off ของประโยชน์นี้คือการขาด holistic agility โดยรวม (ความสามารถของทั้งระบบในการตอบสนองต่อการเปลี่ยนแปลงได้อย่างรวดเร็ว)

layered architecture เป็น architecture แบบ technically partitioned (ตรงข้ามกับ architecture แบบ domain-partitioned ) หมายความว่า ดังที่คุณได้เรียนรู้ใน Chapter 9 component ต่าง ๆ จะถูกแยกตามบทบาทเชิงเทคนิคใน architecture (เช่น presentation หรือ business) แทนที่จะแยกตาม domain (เช่น customer) ผลก็คือ business domain ใด ๆ จะถูกกระจายอยู่ทั่วทุก layer ของ architecture ตัวอย่างเช่น domain ของ “customer” จะมีอยู่ใน Presentation layer, Business layer, Rules layer, Services layer และ Database layer ทำให้การเปลี่ยนแปลง domain นั้นทำได้ยาก ด้วยเหตุนี้ แนวทาง DDD จึงไม่ค่อยเหมาะกับ layered architecture style เท่าไรนัก