ADR-001 - モジュール式アーキテクチャ

ADR-001: モジュール式アーキテクチャ

XOOPSのコアモジュール式設計哲学のためのアーキテクチャ決定記録

ステータス

承認 - XOOPS開始以来の基本的な決定

コンテクスト

XOOPS (eXtensible Object-Oriented Portal System) は以下を可能にするアーキテクチャが必要でした:

サードパーティ開発者が機能を拡張
サイト管理者がコーディングなしでカスタマイズ
独立開発とアップデート
異なる機能間の分離
小さなブログから複雑なポータルまでスケール

2000年代初期のCMS環境はカスタマイズと拡張が難しいモノリシックシステムを提供しました

決定図

graph TB
    subgraph "XOOPSコア"
        A[カーネル]
        B[データベース レイヤー]
        C[ユーザー システム]
        D[テンプレート エンジン]
        E[セキュリティ]
    end

    subgraph "モジュール システム"
        F[モジュール ローダー]
        G[モジュール レジストリ]
        H[モジュール アクセス権限]
    end

    subgraph "インストール済みモジュール"
        I[ニュース モジュール]
        J[フォーラム モジュール]
        K[ギャラリー モジュール]
        L[カスタム モジュール]
    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. コアがインフラストラクチャを提供

データベース抽象化
ユーザー認証とアクセス権限
テンプレートレンダリング(Smarty)
セキュリティユーティリティ
フォーム生成
共通ユーティリティ

2. モジュールは自己完結型

各モジュール:

独自のディレクトリ構造を持つ
独自のクラス、テンプレート、SQLを含む
独自の構成を定義
独立してインストール/アンインストール可能
バージョン追跡

3. 標準モジュール構造

modules/modulename/
├── admin/                  # 管理インターフェース
│   ├── index.php
│   └── menu.php
├── class/                  # PHPクラス
├── include/                # インクルード ファイル
├── language/               # 翻訳
├── sql/                    # データベース スキーマ
├── templates/              # Smarty テンプレート
├── blocks/                 # ブロック定義
├── xoops_version.php       # モジュール マニフェスト
├── index.php               # エントリ ポイント
└── header.php              # モジュール ブートストラップ

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. モジュール通信

コアAPI経由(ハンドラー、イベント)
データベース関係
プリロードフック
共有サービス

モジュールライフサイクル

stateDiagram-v2
    [*] --> Available: modules/にアップロード
    Available --> Installing: 管理者がインストールをクリック
    Installing --> Installed: SQL実行、レコード作成
    Installed --> Active: 管理者がアクティベート

    Active --> Updating: 新バージョンがアップロード
    Updating --> Active: アップデート スクリプト実行

    Active --> Inactive: 管理者が無効化
    Inactive --> Active: 管理者が再度有効化
    Inactive --> Uninstalling: 管理者がアンインストール

    Uninstalling --> Available: ファイルを保持
    Uninstalling --> [*]: ファイルを削除

結果

ポジティブ

拡張性: コミュニティによって作成された何千ものモジュール
独立性: モジュールは個別に開発可能
柔軟性: サイトは機能をミックスマッチ可能
保守性: アップデートは他のモジュールに影響しない
マーケットプレース: モジュールエコシステムが出現
学習曲線: 開発者は1つのパターンを学習

ネガティブ

オーバーヘッド: 各モジュールはブートストラップコストを持つ
重複: 共通コードが繰り返される可能性
統合: クロスモジュール機能は慎重な設計が必要
バージョニング: モジュール互換性管理が必要
品質差: サードパーティモジュール品質が異なる

ニュートラル

データベース: 各モジュールは独自のテーブルを管理
テンプレート: テーマは様々なモジュールに対応する必要
アップデート: コアとモジュールは独立してアップデート

代替案の検討

1. モノリシックアーキテクチャ

却下 - 厳格すぎて、カスタマイズが難しい

2. プラグインアーキテクチャ (WordPress スタイル)

部分的に採用 - ブロックとプリロードはモジュール内でプラグインのようなフックを提供

3. コンポーネントアーキテクチャ (Joomla スタイル)

却下 - より複雑で、開発者フレンドリーではない

4. マイクロサービス

該当なし - 共有ホスティング時代には複雑すぎる

参照

XOOPSプロジェクト履歴
PHPアプリケーションアーキテクチャパターン
CMSの比較研究 (2001-2005)

#xoops #architecture #adr #modules #design-decision