architecture-paradigm-microkernel

マイクロカーネル（プラグイン）アーキテクチャのパラダイム

使用する場合

• プラグインアーキテクチャを備えた拡張可能なシステムを構築する場合
• 顧客ごとのカスタマイズが必要な製品

使用しない場合

• プラグインによる拡張性が求められないモノリシックアプリケーション
• すべての機能がコアであり、設計上密接に結合しているシステム

このパラダイムを採用する場合

• プラットフォーム、統合開発環境（IDE）、データ取り込みパイプライン、またはサードパーティがコア機能を拡張する必要のあるマーケットプレイスを構築する場合。
• コアシステムには極めて高い安定性が求められる一方で、拡張機能や機能を迅速に進化・変更させる必要がある場合。
• オプションの依存関係を分離し、プラグインから提供される信頼できないコードをサンドボックス化することが重要な場合。

導入手順

1. コアサービスを定義する：スケジューリング、コンポーネントのライフサイクル管理、コアドメインのプリミティブ、メッセージングなど、マイクロカーネルの最小限の責務を明確に定めます。
2. プラグインの契約を規定する：登録手順、機能の記述子、ライフサイクルフック（例：起動、停止）、権限モデルなど、すべてのプラグインに適用される正式な契約を設計し、文書化します。
3. 拡張機能ローダーとサンドボックスを構築する：拡張機能の読み込み、バージョン互換性の確認、機能のネゴシエーション、障害の連鎖を防ぐためのプラグインの隔離を行う仕組みを実装します。
4. ソフトウェア開発キット（SDK）を提供する：プラグイン開発を促進するため、プロジェクトテンプレート、テストハーネス、互換性チェックツールを備えた SDK を提供します。
5. リリースプロセスを管理する：コアとプラグインのバージョン間の互換性マトリックスを明確に維持します。さまざまなプラグインに対してコア機能を検証する、自動化されたリグレッションテストスイートを実装します。

主な成果物

• コアとプラグインの責務の分担、およびプラグイン開発と認定のガバナンスモデルを説明するアーキテクチャ決定記録（ADR）。
• プラグインが利用できる機能を詳述した、セキュリティおよび権限モデルの正式なドキュメント。
• リントを実行し、テストを実施し、サンドボックス環境内でプラグインを実行する、自動化されたプラグイン検証パイプライン。

リスクと軽減策

• プラグインの無秩序な増加：
  • 軽減策：選定プロセスがなければ、多数のプラグインをサポートする保守コストが持続不可能になる可能性があります。すべてのサードパーティ製プラグインに対し、正式な認定プロセスまたはマーケットプレイス形式の審査を義務付けます。
• コアとプラグインのバージョンの不一致：
  • 軽減策：コアとプラグインの両方で、セマンティックバージョニング（SemVer）を厳格に適用します。必要に応じて、古いプラグインとの後方互換性を維持するための抽象化レイヤーまたは「シム」を提供します。
• コアシステムの肥大化：
  • 軽減策：安定したコアに機能ロジックを追加しようとする圧力は、しばしば生じます。この誘惑には断固として抗います。コアは最小限に保ち、新機能は可能な限りプラグインとして実装します。

具体的なコンポーネント

このパラダイムの実装で使われる傾向にあるツールや抽象化の用語集です。依存関係ではなく、tools: のフロントマターでもありません。

• plugin-loader：実行時にプラグインを検出、検証、有効化します
• sandbox-executor：制限された機能セットを持つ隔離されたコンテキストで、各プラグインを実行します
• sdk-generator：カーネルの安定したインターフェースから、言語固有の SDK を生成します

終了条件

• ADR に、マイクロカーネルの最小限の責務、プラグインの契約（登録、機能記述子、ライフサイクルフック）、および権限モデルが記載されています。
• サードパーティ製プラグインの開発を開始する前に、正式なプラグイン SDK または仕様（テンプレート、テストハーネス、互換性チェッカー）が用意されています。
• 自動プラグイン検証パイプライン（リンター、テスト、サンドボックス実行）が稼働しており、プラグイン認定の必須条件となっています。
• コアバージョンとサポート対象のプラグイン API バージョン間の互換性マトリックスが公開されており、コアのプラグイン契約が変更されるたびに更新されています。