アーキテクチャレベルで依存性を逆転させたら最高だった話 - Slidev

アーキテクチャレベルで依存性 を逆転させたら最高だった話 ドメインの蒸留とRezept as a Serviceの実現 @katzumi(かつみ) Press Space for next page

自己紹介 （かつみ）と申します。 katzumi 「障害のない社会をつくる」をビジョンとする「LITALICO（りたりこ）」に所属しています 以下のアカウントで活動しています。 katzchum k2tzumi katzumi

• https://twitter.com/katzchum
• https://github.com/k2tzumi

レセプト業務の背景と課題 🏥 レセプト業務とは 障害福祉・介護福祉サービスの利用料を保険者に請求する業務 複雑なドメインゆえミスが許されない 3年に一度の大きな報酬改定でロジックが大幅に変更 📅 法改正対応の困難さ 情報公開から実装完了まで約3ヶ月という短期間 年々複雑化するシステムに対応する必要 今年は補正予算の影響で更に困難な状況 📈 ビジネス拡大の影響 前回（2021年）: 3種類のサービス対応

システム進化の歴史 度のリアーキテクチャを経た変遷 2 年以前 2024 年のリアーキテクチャ アーキテクチャの特徴 2021 モノリシックな構成 レセプトコンポーネント同士の密結合 お互いのAPIを呼び合う構成 2021 時系列で関心事を分離 振り分け層をアプリケーションとして実現 請求業務アプリからレセプト業務が独立 年の新アーキテクチャ を確立 プロダクトとの責務が明確化 依存関係が一方通行に Rezept as a Service マルチテナントなシステムとして設計 シングルユースの構成で各プロダクトのVPC上に構 築 アーキテクチャレベルでの依存性逆転を実現

コアドメインの蒸留

コアドメインの見極め 本質的な責務とそうでない部分の切り分け ❌ レセプト業務ではない責務 利用者への負担額請求 保険者への利用料請求とは別の責務 別システムとして切り離し 各プロダクト特有の機能要件 レセプト業務の本質的責務ではない プロダクト側で責任を持つべき領域 ✅ レセプト業務の本質的責務 保険者への利用料請求 法令に基づいた正確な計算 複雑な算定ロジックの実装 報酬改定への対応 法改正による仕様変更 正確性と迅速性の両立 結果: システム設計がシンプルになり、保 守性も向上

依存性を逆転させる

従来の依存関係の問題 データの流れと依存関係が同じ方向 🔽 従来のアーキテクチャ 各プロダクト 実績データ 🔄 依存性逆転後 各プロダクト API インターフェース レセプトシステム レセプトシステム 請求処理 請求処理

依存性逆転による具体的な効果 🔗 システム間の結合度低下 ⚡ 並行開発の実現 各プロダクトの実装変更がレセプトシステムに影響し 法改正対応で各チームが同時に開発を進められる ない 🎯 責務の明確化 レセプト業務の本質的な責務にのみ集中可能 🛡️ 安定性の向上 上位モジュールとして振る舞い、変更に強い 📋 インターフェース仕様の重要性 契約としてのAPI定義 スキーマ駆動開発の採用 厳密なテストケース設計が可能 🔄 開発プロセスの最適化 手戻りの最小化 品質担保と開発効率の両立

Rezept as a Service として確立

コアドメインとして依存をなくすことのメリット 最も安定したサービスとしての確立 🎯 責務がより明確に 💬 コミュニケーションコストの最小化 📋 I/F仕様書に向き合ってテスト ⚡ システム全体の開発アジリティ向上 外部の動向に注意を払う必要がなくなった レセプト業務の本質的な責務にのみ集中 関心事の分離が完全に実現 インターフェース仕様に基づいた厳密なテスト 実績データの詳細パターンを考慮不要 全体の品質担保がより確実 各プロダクトチームが自身のペースで開発 チーム間での不要な調整が減少 本質的な開発に集中できる環境 スキーマ駆動開発の採用 並行開発による開発サイクル短縮 早期テスト実施による品質確保

コミュニケーション設計の重要性 多くのプロダクトから依存される中心的なシステムとして 📋 明確なサービス定義と仕様合意 法解釈から算定要件への変換 抽象的な法規定を具体的な要件に システムインターフェースへの落とし込み 各プロダクトチームとの協業 📚 ドメイン知識の活用 内のドメインエキスパート 豊富な現場ノウハウの蓄積 SaaSとしての多事業所サービス提供経験 LITALICO 📖 バージョニングされた高品質ドキュ メント セルフサービス型の理想状態 ドキュメントとアプリケーションの一貫性 バージョン管理とリリースノートの整備 柔軟なリリースフロー 🤖 自動化の重要性 開発プロセス全体の自動化 CI/CD Test Nightでの発表内容 ドキュメント生成とコードの紐付け

コアドメインを一番安定させるために 品質の重要度増加への対応 🔧 スキーマ駆動開発の確実な実施 🧪 APIシナリオテストの導入 📋 スキーマ自体の品質向上 📚 ドキュメント化と知識共有 スキーマ品質がプロジェクト全体の成否を左右 実装と乖離させないフロー OSSライブラリ「eg-r2」の開発 スキーマファーストの開発 実装との一貫性担保 継続的な品質改善 の活用 効果的なテスト戦略の確立 全機能のAPI提供に対応 runn チュートリアル本の公開 一人アドベントカレンダーの活用 継続的な知識蓄積

• https://github.com/k1LoW/runn

なにが最高なのか？

当初想定以上の効果 🎯 責務がより明確になり、関心事にのみ集中 外部動向への注意が不要になり、本質的な業務に専 念 📋 I/F仕様書に向き合ってテストできる インターフェース契約に基づいた厳密なテスト設計 💬 コミュニケーションコストを最低限に 各プロダクトチームの自立的な開発を実現 ⚡ システム全体の開発アジリティ向上 並行開発によるプロジェクト全体の開発サイクル短縮 📊 法改正対応での価値 以前：下流工程での大量テストケース消化 現在：早期段階からの十分なテスト実施 結果：品質確保と開発効率の両立を実現 コアドメインの独立性確保により、スキーマ駆動開発を円滑に実行し、目標以上の成果を達成

度のリアーキテクチャを振り返る 2 段階的なアプローチの価値 🎯 段階的アプローチの利点 ✅ 各フェーズでの学び 📈 徐々に確立された要素 🚀 結果として得られたもの 最初から完成形を目指さない システムとビジネスの理解を深める 段階的な改善による本質的なシステム構築 コンポーネント間の依存関係最小化 2. Rezept as a Serviceを中心とした設計 3. インターフェースによる明確な契約定義 4. スキーマ駆動開発の本格導入 1. 実際の連携経験から実用的なインターフェース設計 システムの実態・運用課題の十分な理解 次の設計への学びの活用 システムの拡張性向上 保守性の向上 法改正対応力の向上 現実的な形での実現

まとめ

本発表のまとめ 🎯コアドメインの蒸留による責務の明確化 実現した取り組み アーキテクチャレベルでの依存性逆転による開発の並行化 スキーマ駆動開発とテスト戦略による品質担保 コミュニケーションコストの最適化 ✨ 得られた成果 法改正という厳しい時間的制約の中でも、高品質なシステムを提供 🙏 感謝

今後の展望 🔄 継続的な改善 🌟 より良いアーキテクチャへ 📚 知識共有 🤝 コミュニティへの貢献 コアドメインの洗練 システムの進化 ドメイン特化型ADRの検討 算定構造決定レコードの開発 レセプト業務特有のドメイン記録 チーム間での効率的な合意形成 依存関係のさらなる最適化 新技術の積極的な導入 開発体験の向上 活動の継続 知見の共有 業界全体への価値提供 OSS

ご清聴ありがとうございました 質問・フィードバックをお待ちしています！ @katzchum katzumi k2tzumi