Architecture Partitioning (การแบ่งพาร์ทิชันสถาปัตยกรรม)

The First Law of Software Architecture กล่าวไว้ว่าทุกสิ่งในซอฟต์แวร์คือ trade-off ซึ่งรวมถึงวิธีที่สถาปนิกแบ่งพาร์ทิชัน component ต่าง ๆ ในสถาปัตยกรรมด้วย เนื่องจาก component เป็นกลไกการควบรวมทั่วไป สถาปนิกจึงสามารถแบ่งพาร์ทิชันมันได้ตามที่ต้องการ มี style ที่พบได้ทั่วไปอยู่หลายแบบ แต่ละแบบก็มี trade-off ต่างกันไป การจัดวาง component แบบหนึ่งโดยเฉพาะที่ส่งผลกระทบอย่างมากคือ top-level partitioning .

จาก architecture style สองแบบที่แสดงใน Figure 9-2 แบบหนึ่งคงคุ้นเคยสำหรับหลายคน นั่นคือ layered monolith (จะกล่าวถึงรายละเอียดใน Chapter 10 ) ส่วนอีกแบบเรียกว่า modular monolith เป็น architecture style ที่ได้รับความนิยมโดย Simon Brown ซึ่งประกอบด้วย deployment unit เดียว เชื่อมโยงกับฐานข้อมูลหนึ่งตัว และแบ่งพาร์ทิชันตาม domain แทนที่จะเป็นความสามารถเชิงเทคนิค (จะกล่าวถึงใน Chapter 11 ) style ทั้งสองแบบนี้แสดงถึงวิธีการทำ top-level partitioning ที่แตกต่างกัน สังเกตว่าในทั้งสองรูปแบบ แต่ละ layer หรือ component ระดับบนสุดมักจะมี component อื่น ๆ ฝังอยู่ภายในอีกที top-level partitioning เป็นสิ่งที่สถาปนิกให้ความสนใจเป็นพิเศษ เพราะมันกำหนด architecture style พื้นฐานและวิธีการแบ่งพาร์ทิชันโค้ด

Figure 9-2. top-level partitioning สองประเภท ได้แก่ แบบเทคนิค (technical) เช่น layered architecture และแบบ domain เช่น modular monolith

การจัดระเบียบ architecture ตามความสามารถเชิงเทคนิค เช่นเดียวกับที่ layered monolith style ทำนั้น เรียกว่า technical top-level partitioning .

รูปแบบทั่วไปของสิ่งนี้ปรากฏใน Figure 9-3 ซึ่งสถาปนิกแบ่งพาร์ทิชันฟังก์ชันการทำงานของระบบตามความสามารถ เชิงเทคนิค ได้แก่ presentation, business rules, services, persistence และอื่น ๆ วิธีจัดระเบียบโค้ดเบสแบบนี้สมเหตุสมผลอย่างแน่นอน โค้ดที่เกี่ยวกับ persistence ทั้งหมดจะอยู่ใน layer เดียวกัน ทำให้นักพัฒนาหาโค้ดที่เกี่ยวกับ persistence ได้ง่าย แม้ว่าแนวคิดพื้นฐานของ layered architecture จะมีมาก่อนหน้านั้นหลายสิบปีแล้วก็ตาม แต่ design pattern อย่าง Model-View-Controller (หนึ่งใน pattern พื้นฐานที่กล่าวถึงใน Head First Design Patterns โดย Eric Freeman และ Elisabeth Robson (O’Reilly, 2020)) ก็สอดคล้องกับ architectural pattern นี้ ทำให้นักพัฒนาเข้าใจได้ง่าย ด้วยเหตุนี้ ในหลายองค์กรจึงถือเป็น architecture เริ่มต้นโดยปริยาย

Figure 9-3. top-level partitioning สองประเภทในงานสถาปัตยกรรม

ผลข้างเคียงที่น่าสนใจอย่างหนึ่งจากความแพร่หลายของ layered architecture เกี่ยวข้องกับวิธีที่บริษัทต่าง ๆ มักจัดที่นั่งในสำนักงานจริงตามบทบาทของแต่ละคนในโปรเจกต์ เพราะ Conway’s Law เมื่อใช้ layered architecture การให้นักพัฒนา backend ทั้งหมดนั่งอยู่ในแผนกเดียวกัน DBA อยู่อีกแผนกหนึ่ง ทีม presentation อยู่อีกแผนกหนึ่ง และอื่น ๆ ก็ดูสมเหตุสมผลอยู่บ้าง

รูปแบบสถาปัตยกรรมอีกแบบหนึ่งใน Figure 9-3 คือ domain partitioning ซึ่งเป็นเทคนิคการสร้างโมเดลสำหรับแตกระบบซอฟต์แวร์ที่ซับซ้อน โดยจัดระเบียบ component ตาม domain แทนที่จะเป็นความสามารถเชิงเทคนิค domain partitioning ได้รับแรงบันดาลใจจากหนังสือ Domain-Driven Design ของ Eric Evans ใน DDD สถาปนิกจะระบุ domain หรือ workflow ที่เป็นอิสระและแยกออกจากกัน (decoupled) microservices architecture style ก็อิงตามปรัชญานี้

modular monolith architecture แบ่งพาร์ทิชันตาม domain หรือ workflow แทนที่จะเป็นความสามารถเชิงเทคนิค เนื่องจาก component มักซ้อนกันอยู่ภายในกันและกัน component แต่ละตัวใน domain-partitioned architecture ที่แสดงใน Figure 9-3 (ตัวอย่างเช่น CatalogCheckout ) อาจใช้ persistence library และมี layer แยกต่างหากสำหรับ business rules แต่ top-level partitioning ก็ยังคงหมุนรอบ domain อยู่ดี