はじめに

"ソフトウェアアーキテクチャの基礎" (https://tech-yoshikipom.hatenablog.com/entry/2023/01/24/220503 で紹介した本) に出てきたプラグインアーキテクチャ（またはマイクロカーネルアーキテクチャ）をWebシステムで使う時に考えたことやSpring Bootを用いたプラグインアーキテクチャの実装を紹介する。アーキテクチャのイメージは以下。

プラグイン アーキテクチャを使う時に考えたこと

Webシステムにおけるプラグイン アーキテクチャの使い所

主に以下の二つの要求をシンプルに解決できると思う。

機能面: 入力(ユーザ、APIのクライアントシステム、リクエストデータ等)によって振る舞いを追加したり減らしたりしたい
保守性: たくさんの手続型のロジックをコンポーネント化 -> 責務の明確化、付け替えや追加が容易

機能面のほうは主にA/Bテストがしたかったり、複数のクライアントからの要求に柔軟に答える必要がでたときの話である。単純なif文やStrategyパターンだけで実装すると入力ごとの処理に差異が増えてくると差分が分かりづらくなり、保守性が一気に落ちることがある。保守性の方は実際に”プラグイン”が要件として必要なわけではないが、プラグインとして処理を実装することで開発体験を向上できる。

検討事項

プラグインアーキテクチャを使うときは以下の点は設計しておきたい。

利用するプラグインの決定方法
- ランタイムで決定: なんらかの方法で実行中でも切り替えられる (例: DBに設定を持って、ツールで変更する)
- コンパイルで決定: ビルドした時点で決まる (例: 設定ファイルにプラグインのリストを書く)
何をプラグインにするか
- 各プラグインの同じインターフェースは同じ
- inputとoutputの設計が必要
複数プラグインの実行方法
- 順次実行
- 並列実行

ここで実装するサンプルでは「コンパイルベースの設定ファイル」、「プラグインの内容はダミー」、「並列実行は未対応」とする。

プラグイン アーキテクチャのSpring Bootによる実装例

使用例

作るものを明確にするため使用例から。

設定ファイルでプラグインを管理
アプリケーションクラスで　コアの処理+プラグインを実行する CoreExecutor を実行
ログで適切にプラグインが呼ばれていることを確認
- groupA: プラグイン1つ、groupB: プラグイン2つ、groupC: プラグイン0

設定ファイル(application.yml)

myapp:
  plugin:
    pluginExecutorNamesMap:
      groupA:
        - fooPlugin
      groupB:
        - barPlugin
        - fooPlugin

アプリケーションクラス

@SpringBootApplication
@Slf4j
@RequiredArgsConstructor
@ConfigurationPropertiesScan
public class PluginSampleApplication implements CommandLineRunner {

  private final CoreExecutor coreExecutor;

  public static void main(String[] args) {
    SpringApplication.run(PluginSampleApplication.class, args);
    System.exit(0);
  }

  @Override
  public void run(String... args) throws Exception {
    log.info("===== run app for 'groupA' =====");
    coreExecutor.execute(new CoreExecutorInput("groupA"));
    log.info("===== run app for 'groupB' =====");
    coreExecutor.execute(new CoreExecutorInput("groupB"));
    log.info("===== run app for 'groupC (no config)' =====");
    coreExecutor.execute(new CoreExecutorInput("groupC"));
  }
}

アプリケーションログ

===== run app for 'groupA' =====
process before plugins is running
FooPlugin is running!
process after plugins is running
===== run app for 'groupB' =====
process before plugins is running
BarPlugin is running!
FooPlugin is running!
process after plugins is running
===== run app for 'groupC (no config)' =====
process before plugins is running
process after plugins is running

設計

core package
- CoreExecutor
  - このフレームワークのエントリーポイント
  - プラグインを呼び出したいタイミングで PluginExecutor を使う
  - プラグインを選ぶためのキーを渡す。今回はこれを pluginGroupName と呼ぶ
- PluginExecutor
  - 必要なプラグインを設定ファイルから読み出して実行する
- Plugin
  - プラグインのインターフェース
plugin package
- プラグインの実装をする。今回はサブパッケージは作らず、実装はサンプルでログを出力するのみ。

実装

https://github.com/yoshikipom/java/tree/main/plugin-sample/src/main/java/com/yoshikipom/dev/pluginsample

他のコードはサンプルであまり内容がないため、プラグインの１実装と PluginExecutorのみ解説。

BarPlugin.java

@Component("barPlugin")
@Slf4j
public class BarPlugin implements Plugin {

  @Override
  public PluginOutput execute(PluginInput pluginInput) {
    log.info("BarPlugin is running!");
    return new PluginOutput();
  }
}

coreパッケージのPluginインターフェースを実装
PluginExecutorにDIするため @Component が必要
@Component("barPlugin") の "barPlugin" をプラグイン名としてapplication.ymlに記述する

PluginExecutor.java

@RequiredArgsConstructor
@Component
@Slf4j
public class PluginExecutor {

  private final PluginConfig pluginConfig;
  private final Map<String, Plugin> pluginMap;

  public void execute(String pluginGroupName) {
    // load config
    List<String> pluginNames = pluginConfig.pluginMap()
        .getOrDefault(pluginGroupName, null);

    // if no plugin config, return
    if (pluginNames == null) {
      return;
    }

    // execute plugins one by one
    for (var pluginName : pluginNames) {
      Plugin plugin = pluginMap.get(pluginName);
      PluginInput pluginInput = new PluginInput(); // you can add any input to this class
      PluginOutput pluginOutput = plugin.execute(pluginInput);
      // consume pluginOutput if necessary
    }
  }
}

pluginConfig -> 設定ファイルの情報をマッピングしたPOJO。
- 設定ロードの詳細は　https://spring.pleiades.io/spring-boot/docs/current/reference/html/features.html#features.external-config
pluginMap -> すべての読み込めるプラグインクラスを持つマップ。キーはpluginGroupName。 Map<String, Plugin> とすることでPluginインターフェスの実装をSpring BootがDIしてくれる
- Mapを用いたDIについての詳細は https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-autowired-annotation
pluginInput/pluginOutput の中身は特に実装していない。アプリケーションに合わせて調整が必要。

おわりに

Spring BootのDIや設定ファイル管理の機能を使うと簡単にプラグインアーキテクチャが実現できた。実装すると検討ポイントや保守性に関するメリットがよくわかった。