DAY 3: CHAPTER 1 — C&C STRUCTURE,
ALLOCATION STRUCTURE & MAPPING
ต่อยอดจาก Module View (Static บนดิสก์) สู่ C&C Structure (Runtime ใน RAM), Allocation Structure (การจับคู่ลง Server/Cloud/ทีม) และทะลวงความเข้าใจเรื่อง Many-to-Many Mapping ที่สถาปนิกมักเข้าใจผิด พร้อม ควิซทดสอบความรู้ 20 ข้อ และเฉลยวิเคราะห์เชิงลึก
Component-and-Connector (C&C) Structure
มุมมองขณะที่ซอฟต์แวร์กำลังถูกเปิดประมวลผลจริงอยู่ในหน่วยความจำ (RAM) หรือสภาพแวดล้อม Runtime:
Components & Connectors
• Components: หน่วยประมวลผลหรือแหล่งเก็บข้อมูลหลักขณะรัน เช่น Web Client Instance, Microservice Pod, Database Process, Search Worker
• Connectors: ตัวกลางและกลไกการสื่อสารปฏิสัมพันธ์ระหว่าง Component เช่น REST API, Apache Kafka Message Bus, gRPC, RPC Channel, Shared Memory
Attachments (การเสียบพอร์ต)
ความสัมพันธ์การเชื่อมต่อระหว่าง Port ของ Component เข้ากับ Role ของ Connector เพื่อส่งต่อข้อมูลและ Event ระหว่างกันในระบบ
Component จะยื่น Ports ออกมา และ Connector จะมี Roles เพื่อระบุว่าใครเป็น Sender/Receiver, Publisher/Subscriber หรือ Client/Server
คุณสมบัติการรัน (Properties)
ตัวแปรและข้อจำกัดเชิงพลวัตที่เกิดขึ้นเมื่อระบบถูกเปิดใช้งานจริงใน RAM:
- เวลาในการตอบสนอง (Latency) & ค่าหน่วงเวลา
- ปริมาณงานสูงสุด (Throughput / Requests per second)
- พฤติกรรม Concurrency, Thread Pools, Mutex Locks
- ระดับความปลอดภัยของการส่งข้อมูล (TLS/mTLS)
Service Structure
แสดง Component ที่เป็นบริการย่อย และ Connector ที่เป็นระบบส่งรับ Message (เช่น REST, gRPC, Message Queue) เพื่อวิเคราะห์ความต่อเนื่องในการให้บริการ (Availability) และความสามารถในการขยายระบบ (Scalability)
Concurrency Structure
แสดงการจัดวาง Component ลงใน Logical Threads / Execution Units เพื่อวิเคราะห์จุดคอขวด (Bottlenecks), Thread Locks, Deadlocks, และการแย่งชิงทรัพยากร (Resource Contention) ในหน่วยประมวลผล
Allocation Structure (มุมมองการจัดวางลงสภาพแวดล้อมจริง)
โครงสร้างที่แสดงการจับคู่ (Mapping) ระหว่างองค์ประกอบซอฟต์แวร์ เข้ากับสภาพแวดล้อมทางกายภาพ คลาวด์ หรือองค์กร:
Deployment Structure
จับคู่ C&C Runtime Components เข้ากับ Hardware / Cloud Processing Nodes เช่น ระบุว่า Docker Container หรือ Pod ตัวไหนถูกติดตั้งไว้บน VM, Kubernetes Worker Node, หรือ Availability Zone ใด
Deployability, Disaster Recovery, Cloud Cost, และ Load Balancing
Implementation Structure
จับคู่ Module View (ซอร์สโค้ด) เข้ากับ โครงสร้างระบบไฟล์จริง (File System) หรือ Git Repository เพื่อระบุว่าไฟล์โค้ดใดถูกเก็บไว้ที่ไดเรกทอรีใดและคอมไพล์ลง Jar/Bundle ใด
Build Pipeline Efficiency, Version Control & CI/CD Packaging
Work Assignment Structure
จับคู่ Module View เข้ากับ ทีมพัฒนาหรือบุคลากรในองค์กร เพื่อกำหนดขอบเขตหน้าที่ความรับผิดชอบ และกำหนดช่องทางการสื่อสารให้สอดคล้องกับโครงสร้างซอฟต์แวร์ (Conway's Law)
Team Autonomy, Project Management & Social Debt Reduction
การแมปข้ามมิติโครงสร้าง (Mapping Between Structures)
ความเข้าใจผิดอันดับหนึ่งคือคิดว่า 3 Views ต้องตรงกันแบบ 1 ต่อ 1 แต่ในความเป็นจริงเป็นความสัมพันธ์แบบ Many-to-Many
กรณีศึกษา: ระบบชำระเงิน PaymentService ในแคมเปญ 11.11
1 Module ➔ 10 Instances ➔ 3 Cloud VMs1. Module View
มีไฟล์ซอร์สโค้ดเพียง 1 ไฟล์ บนระบบควบคุมเวอร์ชัน (Git Repository):
📄 PaymentService.javaความรับผิดชอบ: ตรวจสอบและตัดเงิน
2. C&C View
ช่วงเทศกาลลดราคา ระบบสเกลเปิดใช้งานเป็น 10 Component Instances ในหน่วยความจำ:
LoadBalancer (Round Robin)
3. Allocation View
Instances ทั้ง 10 ตัว ถูกจับคู่กระจายไปรันอยู่บน 3 Virtual Machines / Cloud Zones:
☁️ VM-1 (Zone A): 4 Instances
☁️ VM-2 (Zone B): 3 Instances
☁️ VM-3 (Zone C): 3 Instances
อย่าเผลอนำ Class จาก Module View ไปลากเส้นต่อสายเข้ากับ Cloud VM ใน Allocation View บนไดอะแกรมเดียวกัน! เพราะเป็นการผสมมิติทัศน์คนละโลก (Static vs Physical) ทำให้สื่อสารล้มเหลวและทีมงานสับสนอย่างรุนแรง
ควิซทดสอบความรู้ 20 ข้อ (Day 3 Comprehensive Quiz)
ครอบคลุมทั้ง 3 หมวดเนื้อหา: C&C Structure, Allocation Structure, และ การแมปเชื่อมโยงข้ามโครงสร้าง
สารบัญเฉลยเร็ว (Day 3 Fast Answer Key Matrix)
ตารางตรวจสอบคำตอบที่ถูกต้องรวดเร็วทั้ง 20 ข้อประจำ Day 3