モノレポ化、そしてその先へ〜ヘンリーのRe-architecting戦略〜

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyrights(c) Henry, Inc. All rights reserved. モノレポ化前のバックエンド（想定） general-api (Accomplishment Team) ● 電子カルテ「Henry」のバックエンド本体 ● SLOC: 13.9万 receipt-api (Receipt Committee) ● general-api から呼び出され、診療報酬制度に関する処理を行い結果を返す計算エンジン ● Accomplishment Team からの依頼を起点に receipt-api をインクリメントする ● SLOC: 14.6万

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyrights(c) Henry, Inc. All rights reserved. 1. サービスの切り方自体の問題 ● 機能を作るのに仕事の引き継ぎや調整を必要とする構造 ● チームの境界付近に非常に難しい問題が落ちている 2. サービス間の関係性の問題 ● receipt-api は general-api の内部で定義されたモデルをそのまま受け取る（スタンプ結合。順応者） ● 一方で呼び出しの方向はgeneral-api → receipt-apiで、この方向の依存も当然ある ● 双方向の依存 3. 1と2 から、1つの機能を作る上で両サービスを同時に修正する必要 ● 分かれて無くていいものが分かれている ● 実質はマイクロサービスではなく分散モノリス課題

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyrights(c) Henry, Inc. All rights reserved. 理想への移行の初手としてモノレポ化を選択 󰢏選択肢1. 既存サービスを一旦1つに統合した後にドメインによる整理を進める道 󰢃選択肢2. 理想的な切り方のサービスを作って既存のものを徐々に移行する道 💡選択肢2を選ばなかった理由: ● 移行が完了しきるまでのカオス増大 ● いつまで経ったも終わらないリスク ● “理想的な切り方” が間違っているリスク 💡一方で選択肢1は: ● サービスの境界面を含む変更がやりやすくなる（着実に目的に一歩近づける） ● 元々密結合なので、アトミックに変更できるようになる利点は大きい（モノレポ化単体でも意味がある） ● 容易に後戻りできるし、未来の選択肢が多い。低リスク。

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyrights(c) Henry, Inc. All rights reserved. モノレポ化までの道 1. 移行を実現するためのワーキンググループを発足 a. 計画の立案 b. モノレポの具体像の立案 c. モノレポ化のためのバックログの作成・管理 d. 週次でプラン＆状況確認 2. ADRの記述 3. 作業日の決定とアナウンス 4. 準備と手順書の作成 5. やっていき → 入念な準備や便利スクリプトのおかげでスムーズに完了

Slide 14

Slide 14 text

Copyrights(c) Henry, Inc. All rights reserved. それはもううまくいった👏 今回は詳細は割愛します。詳しくはこちらを読んでみてください。 https://dev.henry.jp/entry/backend-monorepo-part-1 医療スタートアップのバックエンドをモノレポ化した話〜戦略・プロセス編〜 https://dev.henry.jp/entry/backend-monorepo-part-2 医療系スタートアップのバックエンドをモノレポ化した話〜技術編〜

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyrights(c) Henry, Inc. All rights reserved. 💡判断の意図: ● ドメインの整理という本丸にすぐに着手できる ● 巨大な泥団子の回避 ○ 未整理のものを統合することで認知負荷増大 → 整理の邪魔になる ● モノリス化によるデメリット（消費メモリやビルド速度の問題）に対処しやすい ○ 今のうちにデメリットの回避のための準備ができる ○ モノリスの期間を短くできるやったこと1. モノリス化→整理ではなく整理→モノリス化を選択

Slide 20

Slide 20 text

Copyrights(c) Henry, Inc. All rights reserved. やったこと2. 境界が明確なモジュールから括り出す 💡判断の意図: ● 整理することで、整理しやすくなる ○ 残ったコードも複雑度が減り整理しやすくなる ○ 高凝集・疎結合なパーツを切り出せれば、他の部分との関係も再定義しやすい ● ビルド速度向上も見込める ○ 分けると並列ビルドしやすい、モジュール単位でビルドキャッシュが効く ● shared … 特定のドメインによらない、ユーティリティ ● master-data … 医療の各制度に基づくマスターデータにアクセスするためのモジュール ○ データは外部からCSV等で配布される＝ヘンリーがモデリングしていないドメイン

Slide 21

Slide 21 text

Copyrights(c) Henry, Inc. All rights reserved. DDDの “境界づけられたコンテキスト” は我々が目指している “ドメインによる分割” のヒントになりそう ● 輪読会 ○ エリック・エヴァンスのドメイン駆動設計 ○ 実践ドメイン駆動設計 ○ マイクロサービスアーキテクチャ ● 議論して理解を深める ○ 抽象的でわかりにくいところもあるので、議論を経て理解を補う ○ 洞察を社内ブログで共有するメンバーもやったこと3. ドメイン駆動設計（DDD）に学ぶ

Slide 22

Slide 22 text

Copyrights(c) Henry, Inc. All rights reserved. やったこと4. コンテキストマップを描く計画 “境界づけられたコンテキスト” を定義し、俯瞰する見取り図（＝コンテキストマップ）をゲットする ● 「始めるためのスタートライン」としての境界を描く ○ より確からしい境界はイテレーティブな取り組みの中で見出されていく ○ その境界はどこまで行っても仮説 ○ スタート地点として最初の仮説を描きたい ● オフラインで集まってガッと描く作戦 ○ 近々やる予定 ○ 只今ワークショップのデザイン中（イベントストーミングをベースにした方法を検討）