STAGE 1 Bill One Engineeringグループ SESSION TAG 前⽥ 英司 Bill Oneで向き合う 外部連携の仕組み

技術本部 Bill One Engineeringグループ Webエンジニア 学⽣時代は会計学を学習し、新卒で開発を始めて、 法⼈税や固定資産のパッケージシステム、Sierで多 くの会社や⾔語に携わる、ベンチャーでWeb開発に 携わるなど、さまざまな開発を経験。 Sansan⼊社後、2021年3⽉からBill One開発に従 事。ドメイン駆動設計やクリーンアーキテクチャな どの設計話が好物。 前⽥ 英司

前提：外部連携とは

- 本スライドで記載する「外部連携」とは、プロダクトの機能として 別のプロダクトのAPIを呼び出し、なんらかの情報を渡すことを指します。 - 別のプロダクトのAPIから情報を受け取り、 ⾃プロダクトの情報として登録する機能は、本スライドの対象外とします。 外部連携とは 前提

Bill Oneにおける外部連携

- Bill Oneでは紙やPDFの請求書を受領してデータ化し、Web上で閲 覧できるため、請求書に関する業務を効率化できる。 - さらに、企業がすでに導⼊しているワークフローシステム、⽀払管 理システム、会計システム等と連携することで、既存の業務プロセ スの中でBill Oneのデータを活⽤でき、請求書に関する業務のデジ タル化をさらに推進できる。 - Bill One – 外部サービス連携 - https://bill-one.com/external_services/ Bill Oneにおける外部連携 外部連携のメリット 社内既存システム

外部連携の⾟いところ

- プロダクトのデータを外部連携先に合わせて変換する必要がある - 外部連携先が送出するエラーを解釈して扱う必要がある - 内容によってはユーザへの通知も検討する必要あり - プロダクトに外部連携先APIの認証認可情報を格納する必要がある - OAuth、APIトークンの利⽤、連携を利⽤するユーザごとなど 連携先によってバリエーションがある - etc.. 外部連携の⾟いところ ⾟いところ

- プロダクトのドメインからできる限り分離したい。 - が、どういう⽅法で分離するか課題となる。 外部連携に対応する場合の⽅針 ⾃プロダクトドメイン （例：請求書管理） 連携先プロダクトへの 接続やデータ変換などの 責務を持った層 連携先プロダクト API 外部連携の⾟いところ

Bill Oneでの外部連携設計

Bill Oneでの外部連携設計 前提：Bill Oneはマイクロサービスを採⽤している 参考：https://speakerdeck.com/sansanbuildersbox/challenging-microservices-in-new-businesses?slide=12

- 分離という⽬的は達成できる - しかし、サービス分割にはコストがかかる - インフラの構築、管理にはコストが必要で、構築段階で最初からマイクロサービスにする？ - チーム構成次第ではマイクロサービスの増加が⾟い場合がある - マイクロサービスにすることで耐障害性は上がるが、連携のトリガーとなる 請求書サービス（invoice）が⽌まっていたらそもそも外部連携も⾏えない 外部連携はマイクロサービスにするべき？ Bill Oneでの外部連携設計

Bill Oneでの外部連携設計 - ただし、実⾏単位としては切り離したいため、GCPのCloud Tasksを利⽤して 独⽴したプロセスとして外部連携を実⾏している （いわゆるドメインイベントとして処理が作成されている） - これにより、Bill Oneで実⾏された外部連携のトリガーとなる処理はそのまま実⾏され、 再実⾏はCloud Tasks単位で⾏うことができるため、ある程度プロダクトのドメインから 外部連携を切り離すことができる。 外部連携は（必ずしも）マイクロサービスにしない

連携先プロダクト 外部連携要否判定 invoice 請求書データ化完了 連携が必要 外部連携 外部連携終了通知 Invoice DB Bill Oneでの外部連携設計 例：とある外部連携処理の流れ

Bill Oneでの外部連携設計 - 処理としては「連携できるか確認」と 「連携の本体」を同じ場所に実装してい る。 - 連携準備をした上でCloud Tasksを呼び 出せば連携できるため、連携のタイミン グを変更する際にもさほど⼤きな変更は いらなくなると想定している 例：とある外部連携処理のプログラムサンプル

Bill One Engineeringグループ Virtual Card 前⽥ 英司