DAY 2: CHAPTER 1 — MODULE STRUCTURE
(มองโค้ดบนดิสก์ / STATIC VIEW)
เจาะลึกโครงสร้างแบบสถิต (Build-time View) ที่อยู่บนดิสก์และระบบควบคุมเวอร์ชัน องค์ประกอบความสัมพันธ์ และ 5 โครงสร้างย่อย (Decomposition, Uses, Layer, Class, Data Model) ที่กำหนดความง่ายในการแก้ไขโค้ด (Modifiability) และการแบ่งทีมพัฒนา พร้อม ควิซทดสอบความรู้ 20 ข้อ และเฉลยวิเคราะห์อย่างละเอียด
นิยามของ Module Structure (มุมมองสถิตบนดิสก์)
ในหมวดหมู่แรกของ 3 Primary Structures สถาปัตยกรรมจะมองซอฟต์แวร์ในรูปแบบของโค้ดที่อยู่บนดิสก์ก่อนการรันประมวลผล:
Modules (หน่วยโค้ด/ข้อมูล)
คือ หน่วยของโค้ดหรือข้อมูล (Code/Data Units) ที่ถูกกำหนดขอบเขตหน้าที่ความรับผิดชอบเชิงคำนวณ (Computational Responsibilities) ไว้อย่างชัดเจน
Classes, Interfaces, Packages, Namespaces, Subsystems, Layers หรือไฟล์ซอร์สโค้ดใน Git Repository
Code & Dependency Relations
ความสัมพันธ์ระหว่างโมดูลที่ปรากฏในโครงสร้างซอร์สโค้ด กำหนดการพึ่งพาและการจัดวางลำดับชั้น
is-part-of: การเป็นส่วนย่อยของโมดูลใหญ่uses / depends-on: การเรียกใช้หรือพึ่งพาโค้ดis-a / inherits-from: การสืบทอดคุณสมบัติallowed-to-use: กฎชั้นอนุญาตให้เรียกใช้
คุณสมบัติของโมดูล
ข้อกำหนดและขอบเขตเฉพาะตัวที่ระบุว่าโมดูลนั้นทำอะไร และคนภายนอกเรียกใช้งานอย่างไรได้บ้าง
- ขอบเขตความรับผิดชอบ (Primary Responsibilities)
- จุดเชื่อมต่อสาธารณะ (Public API / Interface)
- ผู้รับผิดชอบดูแล (Owner Team / Developer)
- ข้อจำกัดการใช้งานและการทดสอบ
เป้าหมายทางวิศวกรรมสูงสุด: ควบคุม Modifiability & Work Assignment
Module Structure คือเครื่องมืออันดับ 1 ของสถาปนิกในการควบคุมและประเมิน Modifiability (ความง่ายในการแก้ไข) เพราะเมื่อ Business Requirement เปลี่ยนแปลง การแก้ไขย่อมเกิดขึ้นกับบรรทัดโค้ดในโมดูลบนดิสก์ ยิ่งไปกว่านั้น มันยังทำหน้าที่เป็น Work Assignment Structure ในการแบ่งทีมพัฒนาตามขอบเขตงานอย่างไม่ก้าวก่ายกัน
5 โครงสร้างย่อยในหมวด Module Structure (5 Key Module Views)
มาตรฐาน SEI จำแนก Module Structure ออกเป็น 5 โครงสร้างย่อยที่นำไปประยุกต์ใช้งานจริงอย่างเป็นรูปธรรม:
1. Decomposition Structure (โครงสร้างการย่อยโมดูล)
แก่นทางวิศวกรรม (Engineering Essence)
ช่วยให้ระบบขนาดใหญ่ถูกย่อยเป็นชิ้นส่วนเล็กๆ แบบ Top-down จนมนุษย์สามารถทำความเข้าใจได้ง่าย เป็นจุดเริ่มต้นแรกสุดของการออกแบบระบบ สถาปนิกใช้มุมมองนี้ในการจัดสรรว่า หากมี Requirement เปลี่ยนแปลง การแก้ไขจะถูกจำกัดวงเป็น Local Change หรือจะระบาดกลายเป็น Nonlocal Change
- Nonlocal Change: ต้องแก้โค้ดลุกลามข้ามหลายโมดูล (สัญญาณเตือนว่า Decomposition ไม่ Cohesive)
การนำไปใช้จริงในองค์กร (Practical Use)
Decomposition มักถูกใช้เป็น Dominant Structure เพราะมันสะท้อนตรงกับโครงสร้างโฟลเดอร์/แพ็กเกจในซอร์สโค้ด และเป็นฐานในการตั้งชื่อทีมพัฒนา (Work Assignment) เช่น ทีม Order Management, ทีม Payment, ทีม Catalog
2. Uses Structure (โครงสร้างการพึ่งพากันเชิงวิศวกรรม)
แก่นทางวิศวกรรม (Engineering Essence)
ในเชิงสถาปัตยกรรม "โมดูล A uses โมดูล B" หมายความว่า ความถูกต้องในการทำงานของ A จำเป็นต้องมีโมดูล B ที่ทำงานถูกต้องอยู่จริง (ไม่ใช่แค่ Stub จำลอง) โครงสร้างนี้ใช้คำนวณและกำจัด Cyclic Dependencies (A เรียก B, B เรียก C, C เรียกย้อน A) ซึ่งเป็นบ่อเกิดของหายนะเวลาคอมไพล์และทดสอบ
การนำไปใช้จริงในองค์กร (Practical Use)
ใช้สำหรับการวางแผน Incremental Development (ส่งมอบงานเป็นรอบๆ) และการดึงเฉพาะกลุ่มฟังก์ชันย่อย (Functional Subsets) เช่น การทำระบบเวอร์ชัน Minimal สำหรับลูกค้ากลุ่มพิเศษ โดยสถาปนิกสามารถตัดส่วนของโค้ดที่ไม่ถูกโมดูลอื่น Uses ออกได้โดยระบบไม่พัง
3. Layer Structure (โครงสร้างชั้นสถาปัตยกรรม)
แก่นทางวิศวกรรม (Engineering Essence)
กฎเหล็กคือ ความสัมพันธ์ต้องเป็น Unidirectional (ทิศทางเดียว) จากบนลงล่างเท่านั้น ห้ามชั้นล่างกระโดดขึ้นมาเรียกชั้นบน แต่ละ Layer ทำหน้าที่เป็น Abstract "Virtual Machine" ที่ซ่อนความซับซ้อนของโครงสร้างชั้นล่างไว้เบื้องหลัง Public Interface
การนำไปใช้จริงในองค์กร (Practical Use)
เพิ่ม Portability (ความยืดหยุ่นในการย้ายระบบ) สูงสุด เช่น หากต้องการเปลี่ยนจาก Oracle เป็น PostgreSQL หรือเปลี่ยน OS จาก Linux เป็น Windows ก็แก้โค้ดเฉพาะที่ Data Access / OS Abstraction Layer ล่างสุด โดย Business Logic ด้านบนไม่ต้องเปลี่ยนแม้แต่บรรทัดเดียว
4. Class / Generalization Structure (โครงสร้างสืบทอดคุณสมบัติ)
แก่นทางวิศวกรรม (Engineering Essence)
อาศัยแนวคิด Object-Oriented Design (OOD) ในการจัดหมวดหมู่พฤติกรรมและการสืบทอดคุณสมบัติ เพื่อส่งเสริม การนำกลับมาใช้ซ้ำ (Reuse) และการขยายระบบผ่าน Polymorphism โดยไม่ต้องแก้ไขโค้ดเดิม (Open/Closed Principle)
การนำไปใช้จริงในองค์กร (Practical Use)
ใช้ในการเขียนแบบแปลน UML Class Diagram เพื่อกำหนดความสัมพันธ์ของคลาสหลักในโดเมน และช่วยให้นักพัฒนามือใหม่เข้าใจโครงสร้างเชิงวัตถุของระบบได้อย่างรวดเร็ว
5. Data Model (โครงสร้างข้อมูลสถิต)
แก่นทางวิศวกรรม (Engineering Essence)
อธิบายโครงสร้างเอนทิตีข้อมูลสถิต (Static Information Structure) และข้อกำหนดความสัมพันธ์เชิงตรรกะที่ถูกนิยามไว้ล่วงหน้าก่อนการจัดเก็บจริง จัดเป็น Module Structure เพราะมันคือการออกแบบพิมพ์เขียวข้อมูลบนกระดาษ/สกีมา ก่อนจะถูกแปลงเป็นข้อมูลจริงในฐานข้อมูล
การนำไปใช้จริงในองค์กร (Practical Use)
ใช้จัดทำ ER Diagram, กำหนด Data Governance, ควบคุม Global Data Consistency ทั่วทั้งระบบองค์กร และประเมินผลกระทบด้านประสิทธิภาพในการ Join ข้อมูล
ควิซทดสอบความรู้ 20 ข้อ (Day 2 Comprehensive Quiz)
ครอบคลุมทั้ง 6 หมวดเนื้อหา Module Structure: นิยาม, Decomposition, Uses, Layer, Class/Data Model และการนำไปใช้จริง
สารบัญเฉลยเร็ว (Day 2 Fast Answer Key Matrix)
ตารางตรวจสอบคำตอบที่ถูกต้องรวดเร็วทั้ง 20 ข้อประจำ Day 2