BtoB SaaSにおける技術課題との向き合い方の"今後の課題"の補足

エンジニアリングマネージャーの竹内です。

11月にこちらのイベントに登壇させて頂きました。

当日は多くの方に見ていただいたようでありがとうございました。アソビューの TECH BLOG をいつも見ているという方からコメントも頂けて嬉しかったです。いろんな方に届いているんだなと改めて実感しました。

さて、この記事では先のイベントで発表した「BtoB SaaSにおける技術課題との向き合い方」の「今後の課題」について少し補足(妄想も含めて)を書きたいと思います。

今後について以下のように書いていました。

連携先の個別対応をうまく分離したい

現状個別対応が既存処理に入り込んでしまっている

今後連携先が増えても追加しやすいようにしたい

様々な外部システムと連携していますが、連携先固有の個別対応がどうしても入ってしまうのでなんとかしたいということでした。

極端でわかりやすくいうと色んな所にこういうことが書かれてしまいます。

  if (is連携先A()) {
      // 連携先固有処理
  }

連携先が少なければまだなんとかなるかもですが、増えてくると大変なことになるのでなんとかしたいところです。

そこで、資料にも書いたようにSaaS 部分と連携先固有処理を分けるインターフェイスを定義して分離を行うのがいいのではと考えました。販売処理の連携を例に擬似コードで書くとこんな感じでしょうか。

  // 外部連携先と販売連携する場合
  販売する(Request request) {
    //  ...略
    Response response = 外部連携IF.販売連携(request);
    // 以降SaaS 販売処理
  }

  // 外部連携IFの実装
  販売連携(Request request) {
    // ここらへんに販売連携処理を書く(連携先のAPIを叩くなど)
  }

とりあえずこういう形にリファクタリングできると良さそうな気がします。（どの連携先の実装を使うかの Factory とか Dispatcher 的なものはいると思いますが割愛します）

これで分離は一定できそうですが、更に個別部分をSaaS外部にしてプラグインやアプリのようにできるとさらに良さそうです。もしかしたら外部の方に作っていただくこともできるかもしれませんね。

そうするとこういうイメージでしょうか。予め設定されている外部連携アプリのURLを webhook として登録しておきそれを呼び出す。

  // 外部連携先と販売連携する場合
  販売する(Request request) {
    //  ...略
    callPlugin(webhookUrl, request);
    // 以降SaaS 販売処理
  }

  // アプリとして実装
  販売連携(Request request) {
    // ここらへんに販売連携処理を書く(連携先のAPIを叩くなど)
  }

外部のアプリとするなら以下のような課題もクリアする必要がありそうですが、これは別の機会にしたいと思います。

アソビューでの開発についてもっと知りたい方はこちらをぜひご覧ください！カジュアル面談もやっておりますので、お気軽にお問い合わせください！