複雑な医療ドメインで試行錯誤してきたヘンリーのアーキテクチャ

アーキテクチャ選択の背景や意図

Point 01. バックエンドサービスのモノレポ化とモジュラーモノリスへの移行

もともとヘンリーのバックエンドは2つのサービス、2つのリポジトリに分かれていました。
General API がユーザーからのリクエストの矢面に立ち、その裏で Receipt API が複雑な医療制度の計算を担う、という設計思想です。

しかし、事業が成長し、ドメインやプロダクトへの解像度が上がるにつれて、この当初の分割境界がもはや理想的ではないことが明らかになってきました。
誤った分割境界が歪みを生み、開発生産性や品質を下げる状況に陥ってしまいました。

この歪みを正し、より適切な境界線を見出すための第一歩がモノレポ化でした。
まず誤った境界を取り払い境界の見直しの試行錯誤をやりやすくし、そこからモジュラーモノリスへと発展させる取り組みに近年挑戦しています。
(参考記事: gRPCで分断されたモノリスを段階的にモジュラーモノリスに移行する)

Point 02. Web App 向けの API 開発を GraphQL に一本化

ヘンリーでは歴史的に、バックエンドサービス間の通信は gRPC、Web App との通信はゲートウェイサーバーが GraphQL と相互変換するという構造を取っていました。
Protobuf のスキーマを中央管理するリポジトリがあり、GraphQL の SDL も Protobuf からコード生成していました。

組織体制の変化に伴い、スキーマの中央管理に伴うコンフリクトやデプロイ整合性の担保が難しく、gRPC の存在が足枷になり GraphQL を本格的に活用できない、などの問題が顕在化していきました。

バックエンドサービスがモノレポ化されたことを契機に、バックエンドが直接 GraphQL をサーブする方針を採用しました。

Point 03. 院内システムとの連携

病院の中には、MRI などの検査機器や、調剤など各部門業務に特化した部門システム、マイナンバーカードによる保険情報の検証システムなど、直接インターネットからはアクセスできないようなシステムが多く存在します。
電子カルテ・レセコンはそれらのシステムと互いにデータを共有し合いながら、業務をスムーズに繋げるのです。

これらのシステムの多くは共有フォルダにファイルを読み書きすることで連携を図るため、病院内の管理サーバーに常駐プログラムを設置し、ファイルシステムを監視しながら、PubSub を介したイベント駆動でバックエンドシステムと双方向の連携をしています。
また認証にはクライアント証明書を利用しています。

現在の課題と今後の改善予定

巨大でドメイン境界が曖昧なプロダクトをいかに組織的に開発していくかという挑戦に終わりはありません。
バックエンドのモジュール分割とサービス統合は今後何年に渡って続くことでしょう。

プロダクトと組織の規模が成長する中で、各領域でボトムアップに設計やアーキテクチャの見直しが盛んに行われています。
その中でドメインと技術の両面から課題の発見と解決を高速で回していくための構造や組織をどうアーキテクトしていくかが一番のテーマです。

◆執筆：岩永 勇輝