---
title: アーキテクチャレベルで依存性を逆転させたら最高だった話 - Slidev
tags:  #アーキテクチャ  
author: [katzumi](https://www.docswell.com/user/katzumi)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/YJ62XMNM7V.jpg?width=480
description: お試しでLLMポン出しでスライドを作成してみました https://x.com/katzchum/status/1946066680201035909
published: July 18, 25
canonical: https://www.docswell.com/s/katzumi/53E6YL-domain-distillation
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/YJ62XMNM7V.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/GJ52XZ5QJ4.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LE3KX9NZE5.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/8ED32GW47G.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/V7P4139VE8.jpg)

コアドメインの蒸留


# Page. 6

![Page Image](https://bcdn.docswell.com/page/2JVXY4MR7Q.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/5EGV91G6EL.jpg)

依存性を逆転させる


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4JQ6WDX2JP.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/K744KZ6P71.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/LJ14XRVXJG.jpg)

Rezept as a Service
として確立


# Page. 11

![Page Image](https://bcdn.docswell.com/page/GJWXN1LKE2.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/4EZ63PMNE3.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/Y762XMN9EV.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/G752XZ5D74.jpg)

なにが最高なのか？


# Page. 15

![Page Image](https://bcdn.docswell.com/page/9J24XRGM7R.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/DEYM8DVPEM.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/VJNWQ6MMJ8.jpg)

まとめ


# Page. 18

![Page Image](https://bcdn.docswell.com/page/YE9XDLNW73.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/GE823XKRED.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/LEL2V8Z27R.jpg)

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


