コア+プラグイン構造系
✅ 概要
この系統は、システムを 最小限のコア(Microkernel)と、拡張可能なプラグイン群 に分割するスタイルを扱う。
- コアは最小限の機能だけを提供
- プラグインが個別機能・拡張・バリエーションを提供
- IDE / OS / ミドルウェアなど、拡張性が重要なソフトウェアでよく見られる構造
代表的なスタイル:
✅ なぜこの系統が生まれたか(歴史・背景)
- OS やコンパイラ、IDE など、長期にわたって機能拡張されるソフトウェアが増えた
- コア機能と拡張機能の境界を明確にしないと、変更コストが爆発する
- 一部機能だけを有効・無効にしたい、というニーズ
- サードパーティに拡張の余地を開きたい(プラグインエコシステム)
「変わりにくいコア」と「変わりやすい拡張」を分けて設計する
という発想から、Microkernel / Plugin 系のスタイルが生まれてきた。
✅ 解決しようとした問題
- 機能追加のたびに既存コードへ大規模な変更が必要になる
- 特定顧客向けのカスタマイズやオプション機能が増えるほど複雑化する
- サードパーティ拡張を許容したいが、コアを壊されたくない
コアとプラグインを分離することで:
- 追加機能はプラグインとして実装
- コアは安定化させ、インターフェースだけを維持
という構造を目指す。
✅ この系統に属するスタイル
- Microkernel Architecture:OS や IDE などで使われる「最小コア+プラグイン」の基本構造
- Plugin Architecture:アプリケーションに拡張ポイントを用意し、外部プラグインで機能追加を行うスタイル
✅ 他の系統との関係
- Layered / Domain Model 系 と組み合わせて、ドメインサービスをプラグインとして差し替える構成もあり得る
- Flow / Reactive 系 の中で、処理ステージやハンドラをプラグインとして差し込む形も一般的
- Cross-cutting(Plugin を用いた拡張性・サードパーティ開発) とも関わる
✅ どんな時に参考になるか
- 長期運用され、継続的な機能追加が見込まれるプラットフォーム
- 顧客ごとに機能セットが異なるプロダクト(機能フラグ+プラグイン)
- サードパーティ向けの拡張ポイントを設計したい場合
「プロダクト」ではなく「プラットフォーム」を作るときに、 この系統の発想が特に重要になる。