ADR-001 - สถาปัตยกรรมแบบแยกส่วน

ADR-001: สถาปัตยกรรมแบบแยกส่วน

บันทึกการตัดสินใจด้านสถาปัตยกรรมสำหรับปรัชญาการออกแบบโมดูลาร์หลักของ XOOPS

---

สถานะ

ยอมรับแล้ว - การตัดสินใจขั้นพื้นฐานตั้งแต่เริ่มก่อตั้ง XOOPS

---

บริบท

XOOPS (eXtensible Object-Oriented Portal System) ต้องการสถาปัตยกรรมที่จะ:

1. อนุญาตให้นักพัฒนาบุคคลที่สามขยายฟังก์ชันการทำงาน
2. ช่วยให้ผู้ดูแลไซต์สามารถปรับแต่งได้โดยไม่ต้องเขียนโค้ด
3. สนับสนุนการพัฒนาและอัปเดตที่เป็นอิสระ
4. ให้การแยกระหว่างคุณลักษณะต่างๆ
5. ปรับขนาดจากบล็อกธรรมดาไปจนถึงพอร์ทัลที่ซับซ้อน

ภูมิทัศน์ CMS ช่วงต้นทศวรรษ 2000 นำเสนอระบบแบบเสาหินที่ยากต่อการปรับแต่งและขยาย

---

แผนภาพการตัดสินใจ

mermaid
graph TB
    subgraph "XOOPS Core"
        A[Kernel]
        B[Database Layer]
        C[User System]
        D[Template Engine]
        E[Security]
    end

    subgraph "Module System"
        F[Module Loader]
        G[Module Registry]
        H[Module Permissions]
    end

    subgraph "Installed Modules"
        I[News Module]
        J[Forum Module]
        K[Gallery Module]
        L[Custom Module]
    end

    A --> F
    B --> F
    C --> H
    D --> F
    E --> H

    F --> G
    G --> I
    G --> J
    G --> K
    G --> L

    H --> I
    H --> J
    H --> K
    H --> L

---

การตัดสินใจ

เราจะใช้ สถาปัตยกรรมแบบแยกส่วน โดยที่:

1. Core ให้โครงสร้างพื้นฐาน

• นามธรรมฐานข้อมูล
• การตรวจสอบผู้ใช้และการอนุญาต
• การแสดงผลเทมเพลต (Smarty)
• สาธารณูปโภครักษาความปลอดภัย
• การสร้างแบบฟอร์ม -สาธารณูปโภคส่วนกลาง

2. โมดูลมีอยู่ในตัวเอง

แต่ละโมดูล:

• มีโครงสร้างไดเร็กทอรีของตัวเอง
• มีคลาส เทมเพลต SQL ของตัวเอง
• กำหนดการกำหนดค่าของตัวเอง
• สามารถติดตั้ง/ถอนการติดตั้งได้อย่างอิสระ
• มีการติดตามเวอร์ชัน

3. โครงสร้างโมดูลมาตรฐาน

modules/modulename/
├── admin/                  # Admin interface
│   ├── index.php
│   └── menu.php
├── class/                  # PHP classes
├── include/                # Include files
├── language/               # Translations
├── sql/                    # Database schema
├── templates/              # Smarty templates
├── blocks/                 # Block definitions
├── xoops_version.php       # Module manifest
├── index.php               # Entry point
└── header.php              # Module bootstrap

4. รายการโมดูล (xoops_version.php)

<?php
$modversion['name']        = 'Module Name';
$modversion['version']     = '1.0.0';
$modversion['description'] = 'Module description';
$modversion['dirname']     = basename(__DIR__);
$modversion['hasMain']     = 1;
$modversion['hasAdmin']    = 1;
$modversion['sqlfile']['mysql'] = 'sql/mysql.sql';
$modversion['tables']      = ['modulename_table1'];
$modversion['templates']   = [...];
$modversion['config']      = [...];
$modversion['blocks']      = [...];

5. การสื่อสารโมดูล

• ผ่าน core APIs (ตัวจัดการ กิจกรรม)
• ความสัมพันธ์ของฐานข้อมูล
• โหลดตะขอล่วงหน้า
• บริการที่ใช้ร่วมกัน

---

วงจรชีวิตของโมดูล

mermaid
stateDiagram-v2
    [*] --> Available: Upload to modules/
    Available --> Installing: Admin clicks Install
    Installing --> Installed: SQL executed, records created
    Installed --> Active: Admin activates

    Active --> Updating: New version uploaded
    Updating --> Active: Update scripts run

    Active --> Inactive: Admin deactivates
    Inactive --> Active: Admin reactivates
    Inactive --> Uninstalling: Admin uninstalls

    Uninstalling --> Available: Keep files
    Uninstalling --> [*]: Remove files

---

ผลที่ตามมา

คิดบวก

1. ความสามารถในการขยาย: โมดูลนับพันที่สร้างโดยชุมชน
2. ความเป็นอิสระ: สามารถพัฒนาโมดูลแยกกันได้
3. ความยืดหยุ่น: ไซต์สามารถผสมผสานและจับคู่คุณสมบัติต่างๆ ได้
4. การบำรุงรักษา: การอัพเดตไม่มีผลกับโมดูลอื่นๆ
5. ตลาด: ระบบนิเวศของโมดูลเกิดขึ้น
6. เส้นโค้งการเรียนรู้: นักพัฒนาเรียนรู้รูปแบบเดียว

เชิงลบ

1. ค่าใช้จ่าย: แต่ละโมดูลมีค่าใช้จ่ายบูตสแตรป
2. การทำสำเนา: รหัสทั่วไปอาจซ้ำกันได้
3. การบูรณาการ: คุณสมบัติข้ามโมดูลจำเป็นต้องมีการออกแบบอย่างระมัดระวัง
4. เวอร์ชัน: จำเป็นต้องมีการจัดการความเข้ากันได้ของโมดูล
5. ความแปรปรวนด้านคุณภาพ: คุณภาพของโมดูลของบริษัทอื่นแตกต่างกันไป

เป็นกลาง

1. ฐานข้อมูล: แต่ละโมดูลจัดการตารางของตัวเอง
2. เทมเพลต: ธีมต้องรองรับโมดูลต่างๆ
3. อัปเดต: อัปเดตคอร์และโมดูลแยกกัน

---

พิจารณาทางเลือกอื่นแล้ว

1. สถาปัตยกรรมเสาหิน

ถูกปฏิเสธ - แข็งเกินไป ปรับแต่งได้ยาก

2. สถาปัตยกรรมปลั๊กอิน (สไตล์ WordPress)

นำมาใช้บางส่วน - บล็อกและโหลดล่วงหน้ามี hook เหมือนปลั๊กอินภายในโมดูล

3. สถาปัตยกรรมส่วนประกอบ (สไตล์ Joomla)

ถูกปฏิเสธ - ซับซ้อนมากขึ้น เป็นมิตรกับนักพัฒนาน้อยลง

4. ไมโครเซอร์วิส

ไม่เกี่ยวข้อง - ซับซ้อนเกินไปสำหรับยุคโฮสติ้งที่ใช้ร่วมกัน

---

การตัดสินใจที่เกี่ยวข้อง

• ADR-002: การเข้าถึงฐานข้อมูลเชิงวัตถุ
• ADR-003: เครื่องมือเทมเพลต Smarty
• ADR-005: ระบบการอนุญาต

---

อ้างอิง

• XOOPS ประวัติโครงการ
• PHP รูปแบบสถาปัตยกรรมแอปพลิเคชัน
• CMS การศึกษาเปรียบเทียบ (2544-2548)

---

#xoops #architecture #adr #modules #การออกแบบ-การตัดสินใจ