読書会から始める関数型ドメインモデリング / Learning Functional Domain Modeling Through a Reading Group

2025/07/15
実践！バックエンドTypeScript〜現場から学ぶtsの可能性〜
https://findy.connpass.com/event/360678/

読書会から始める関数型ドメインモデリング

倉澤 直弘
ソフトウェアエンジニア

Transcript

1. 読書会から始める 関数型ドメインモデリング 実践！バックエンドTypeScript 〜現場から学ぶtsの可能性〜 @20250715
2. 自己紹介 • 名前: 倉澤 直弘 • 所属: 株式会社カミナシ • 役割: ソフトウェアエンジニア • 経歴: 2022年7月、カミナシに入社。 カミナシレポートの開発、その後マネージャーを経て 今年の4月からカミナシ教育チームに開発者としてJoin しました。 Xアカウント: @k_7016
3. カミナシとは ノンデスクワーカー向けの現場 DX SaaS を提供
4. プロダクトラインナップ カミナシは“現場の基盤”となる 3つの領域をまたぐデジタルインフラに Method 作業 Men ⼈ Machine 設備 電⼦帳票 マニュアル‧研修 コミュニケーション 設備カルテ 1つのアカウント運⽤で複数のシステムを利⽤。運⽤の負担軽減とセキュリティ向上
5. 5 Agenda 1. はじめに 2. ドメイン駆動設計の目的 3. 3つのステップ ◦ ステップ 1: ドメインを理解する ◦ ステップ 2: ドメインをモデリングする ◦ ステップ 3: モデリングから実装を導く 4. 書籍の感想 5. さいごに
6. 1. はじめに
7. • 今日はバックエンド TypeScript の設計改善のために行った「関数型ドメインモデリング」の読書会から学 んだ内容をシェアさせていただきたいと思います。 • 現在、バックエンドに TypeScript を使っている私のチームでは、TypeScript に適したアーキテクチャを 模索中です。 書籍について ◦ 「関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう」 ◦ Scott Wlaschin (著), 猪股 健太郎 (翻訳) ◦ https://www.amazon.co.jp/dp/4048931164 ◦ F# で説明されているためTypeScript にそのまま適用できないものもあります 読書会の方法について ◦ 毎週水曜日 ◦ 朝 9:00 ~ 10:00 ◦ 予習は特にせずに来て、1章ずつ45分くらいまでもくもく読書 ◦ さいご15分で感想を共有 1. はじめに
8. 今日の話の前提 今日は持ち時間が10分ということもあり、詳細にはあまり立ち入らずに説明させていただきます。 そのため、詳細な How や実装の手法はあえて削っています。 その辺の話が聞きたかった方はすみません。 今日の話のポイント 書籍ではまずドメイン駆動設計の目的である「共有されたモデル」を作る重要性を説明し、 その目的を達成するための3 つのステップを説明しています。 1. ドメインを理解する 2. ドメインをモデリングする 3. モデリングから実装を導く そしてその際に重要なのは以下の2点だと学びました。 • 技術的制約をモデリングに持ち込まないこと • コードによって文書化することで実装とモデルの乖離をなくすこと 今日は上記に挙げたポイントを中心にお話しします。 1. はじめに
9. 今日のポイントのイメージ図 1. はじめに
10. 2. ドメイン駆動設計の目的
11. 2. ドメイン駆動設計の目的 共有されたモデルを持つ ソフトウェア開発において、「問題の理解度」は「ソリューションの質」に直結します。 私たちがどれだけ時間をかけてドメインエキスパートから話を聞いても、最終的に本番環境にリリース されるのは「ドメインエキスパートの理解」ではなく、「開発者の理解」が反映されたコードです。 仕様書や要件定義書を介したコミュニケーションや、あるいはドメインエキスパートが持つ「理解」を コードに翻訳する過程で、ビジネスの意図とコードの間にずれが生じることが起こります。 DDDの目標は、このずれをなくし、ドメインエキスパートと開発者、またソースコードまでが翻訳のい らない「共通の理解（共有されたメンタルモデル）」を持つことです。 これにより、ビジネスの意図が直接コードに反映され、真に価値のあるシステムを生み出すことを目指 します。
12. 3. 3つのステップ
13. 3. 3つのステップ ステップ1: ドメインを理解する DDDでは、技術的な制約からではなく、ドメインから理解し、設計します。 これは、データベース駆動設計やクラス駆動設計で陥りがちな、技術的な思考によってドメインを歪め てしまうことを避けるためです。 設計時に特に重視するのは、データ構造ではなく、ビジネスイベントやワークフローです。ビジネスは 単にデータを持っているだけでなく、データを変換することで価値を生み出します。 このデータ変換のきっかけを「イベント」と呼び、イベントストーミングなどの手法を用いてドメイン 内のイベントを発見します。 また、ドキュメントはUML図のようなものではなく、シンプルなテキストで記述していき、最終的には コード自体がドキュメントとなることを目指すことが提案されていました。
14. ステップ2: ドメインをモデリングする 3. 3つのステップ ドメインは型を使ってモデリングします。そして、その型が重要な役割を担います。 一つは、ドメインモデルを直接コードの型で表現することで、モデルからコードへの翻訳作業が不要になり、設 計と実装の乖離を防ぐこと。 もう一つは、型自体がドキュメントとして機能することです。理想的にはドメインエキスパートなどの非開発者が コードをレビューしたり設計を確認できることが望ましいです。 ユビキタス言語における名詞であるデータ構造はもちろん、動詞であるビジネスプロセスもワークフローとして関 数型としてモデル化します 。 さらに、型によってビジネスルールを厳密に表現し、不正な状態をそもそも表現できないようにすることで、シス テムの完全性と整合性を確保します。これにより、必要なユニットテストの量を減らすことにも繋がります。
15. ステップ3: モデリングから実装を導く 3. 3つのステップ 型によってモデリングされたものを、型にそって実装します。ビジネスプロセスは入力を受け取り、出力を生成するワークフローとして 実装します。 書籍では、このワークフローを純粋関数の連鎖(パイプライン)として実装することを推奨します。純粋関数は、同じ入力に対して常に 同じ出力を返し、外部の状態を変更しない（副作用がない）ため、予測可能でテストしやすいという大きな利点があります。 ビジネスロジックを純粋関数で表現することで、その意図が明確になり、複雑なビジネスプロセスも小さな、独立した、再利用可能な 部品に分割できます。これにより、個々のビジネスロジックの理解と検証が容易になります。 また、このビジネスロジックの純粋性を守るために、アーキテクチャが重要です。 オニオンアーキテクチャのように、ドメインを内側に、インフラを外側に配置し、各レイヤーが内側のみに依存し、外側には依存しない ように設計します。 特に重要なのは、I/O（副作用）を可能な限り避けることです。データベースへのアクセスなどの副作用が発生する処理は、ワークフ ローの「端」に追いやり、ビジネスロジックの純粋性を保ちます。
16. 重要な2点についておさらい 3. 3つのステップ 「共有されたモデル」を作るために実装上の都合や技術的制約をモデリングに持ち込まないこと • 1つ目のステップでデータベース駆動設計やクラス駆動設計を行わず、シンプルなテキストでドメインを整理しする • 技術の話を持ち込まないことによって、DDDの目的である「共有されたモデル」を作ることができるようになります • ドメインエキスパートは技術のことは知らないため技術的部分が入ってくると「共有されたモデル」にならないため コードで「共有されたモデル」を文書化することで実装とモデルの乖離をなくすこと • コード自体がドメインモデルとなるのでモデルからコードへの翻訳作業が必要なく、実装との乖離を防げます。 • コード自体をドキュメントとして使うことで、ドメインエキスパートや非開発者がレビューし、設計を確認できます。
17. 今日のポイントのイメージ図 (加筆して再掲) 3. 3つのステップ
18. 4. 書籍の感想
19. • この書籍を読んで自分は 「DDDにおけるドメインをモデリングする部分と、モデルを実装する部分 (設計 や実装のパターンなど) がごっちゃになっていてた」と気づきました。 この書籍ではまず DDD の目的を把握して、ドメインを理解し、モデリングし、その後、実装するという流 れになっていて、「モデリングのための話なのか」、それとも「実装のための話なのか」がわかりやす かったです。 そもそも、関数型プログラミングとしての実装方法の話は多かったですが、DDDとしての実装パターンは そこまで多くなく、それが逆に良かったと思いました。 • 今まで DDD のモデリング手法はなんか小難しそうって勝手に思っていましたが、書籍で紹介されていた手 法であれば、イベントストーミングだけなんとかできれば、後はシンプルなテキストとコードでまとめて いくだけなので私でもできそうって思いました。 • 今日は関数型プログラミングの話は省いたため詳細は省きますが、書籍は F# で説明されていたこともあ り、TypeScript の機能的に足りない部分はあるため、完全にこの本の内容を実践することは難しいかもし れないと思ってます。しかし、今日話したような DDD の考え方、進め方は、関数型言語以外でも活かせる 内容だと思いました。 4. 書籍の感想
20. 5. さいごに
21. • 今日は、「関数型ドメインモデリング」という書籍から私が学んだことを発表させていただきまし た。 • 今日話せたのは書籍のほんの一部分、特に具体的な How や関数型プログラミングの話はほぼでき ていなかったため、今日の話を聞いて興味を持てた方は、ぜひ実際に書籍を読んでみていただきた いです！ 5. さいごに
22. 5. さいごに • 今日の勉強会の趣旨に合いそうな話を以前、チームの同僚が別の勉強会でやっているので気になる方はぜひ以下の 資料もご覧ください。 https://speakerdeck.com/kaminashi/how-was-adopting-backend-typescript-in-a-golang-company • 実は今日の話はこの発表の続編的な立ち位置でもありました。 Appendix
23. 5. さいごに ご静聴ありがとうございました！ カミナシでは積極採用中です！ TypeScriptで開発する私のチームで、 まずはカジュアル面談しませんか？ 右記のQRコードからぜひお気軽にご応募ください！ カジュアル面談のご応募はこちら