関数型ドメインモデリングの理想と現実 / Domain Modeling Made Functional: Ideals vs. Reality

目次 Manager / EM 1-1. なぜ関数型ドメインモデリング？ 1-2. 関数型に固執した失敗と学び 1-3. Event
Sourcing のアプローチでの解決 2-1. 入居時オンボーディングとは 2-2. 難しいポイント 2-3. 良ったこと Member 2-4. 大変だったこと 2-5. まとめ 2 Copyright © 2025 Bitkey Inc. All right reserved.

目次 1-1. なぜ関数型ドメインモデリング？ 1-2. 関数型に固執した失敗と学び 1-3. Event Sourcing のアプローチでの解決 2-1.
入居時オンボーディングとは 2-2. 難しいポイント 2-3. 良ったこと 2-4. 大変だったこと 2-5. まとめ 3 Copyright © 2025 Bitkey Inc. All right reserved.

自己紹介佐藤拓人 Sato Takuto @takuuuuuuu777 2015.04 大学(建築学専攻)卒業後、株式会社ワークスアプリケーションズに入社会計システムのソフトウェア開発を担当
特に財務会計の仕訳関連 2019.05 ビットキーへ参画 ECサイトの開発 / 保守、社内システムの開発 TaKuTyの開発 2020.01 今のhomehub事業の前身となるResidenceチームに配属。スマートロックを扱う管理画面やバックエンド、スマホアプリの開発に従事 Now homehub事業のプロダクト責任者複雑な事象を読み解いて構造化し、抽象化 / 汎用化でるように設計し、低コストで多の価値をだせる開発をすることを好む 4 Copyright © 2025 Bitkey Inc. All right reserved.

自己紹介佐藤拓人 Sato Takuto @takuuuuuuu777 5 Before After Copyright
© 2025 Bitkey Inc. All right reserved.

1. なぜ関数型ドメインモデリング？ 6 Copyright © 2025 Bitkey Inc. All right
reserved.

1. なぜ関数型ドメインモデリング？背景 / 課題・過去にスパゲッティ化加速されてしまった状態の改善のために「DDD」を導入していた・当初は「ドメイン駆動」より、機能追加や修正時に「壊れづらい構造」を重要視して開発をしていてた・ある程度「DDD」の構造進んで課題となったのは「モデリングの共通認識」
・境界づけられてたコンテキストなどの理解や業務理解などのために、イベントストーミングなどを実施した解決しれなった...。 7 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ関数型ドメインモデリング？背景 / 課題・過去にスパゲッティ化加速されてしまった状態の改善のために「DDD」を導入していたそもそもモデリングが難しい... ・当初は「ドメイン駆動」より、機能追加や修正時に「壊れづらい構造」を重要視して開発をしていてた
・ある程度「DDD」の構造進んで課題となったのは「モデリングの共通認識」・境界づけられてたコンテキストなどの理解や業務理解などのために、イベントストーミングなどを実施した解決しれなった...。 8 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ関数型ドメインモデリング？ ▪ モデリングとは？ - 現実を模倣して単純化したもの単純化のために、情報を取捨選択して削落とす ▪ 目的・メリット
- 単純化するため、実装しやすくなる単純化するため、変更しやすくなる単純化した結果共通項が明確になり共通化しやすくなる ▪ 例：地図 9 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ関数型ドメインモデリング？ ▪ モデリングとは？ - 現実を模倣して単純化したもの単純化のために、情報を取捨選択して削 ▪ 目的・メリット -
落とすこれが難しい単純化するため、実装しやすくなる単純化するため、変更しやすくなる単純化した結果共通項が明確になり共通化しやすくなる ▪ 例：地図 10 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ関数型ドメインモデリング？モデリングの難しさ 1. そもそも抽象化難しい 2. 粒度や取捨選択難しい 3.
これを局所最適ではな 4. 「創造」の側面強全体最適とするの、これ難しい良いという共通認識を取りづらい 11 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ関数型ドメインモデリング？ 13 Copyright © 2025 Bitkey Inc. All right
reserved.

1. なぜ関数型ドメインモデリング？これも難しかった 14 Copyright © 2025 Bitkey Inc. All
right reserved.

2. 関数型に固執した失敗と学び 15 Copyright © 2025 Bitkey Inc. All right
reserved.

1. なぜ関数型ドメインモデリング？失敗・取り入れたい要素を見誤ってしまった... 補足・元々の課題はモデリング・関数型という具体的な実装方法に固執する必要・実装方法ではな・にもな
った、モデリングの考え方 / アプローチに取り入れたったわらず、実装方法も関数型に限定して固執してしまった学び・Event Sourcing でモデリングに対する関数型アプローチを実現可能だった 16 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ Event Sourcing を導入しようと思ったのプロダクト特性 ※ かなり簡易化した図となっています 21 Copyright

1. なぜ Event Sourcing を導入しようと思ったのプロダクト特性解錠できるか / できないがコントロールできない
... ↓ 事業リスク ※ かなり簡易化した図となっています 24 Copyright © 2025 Bitkey Inc. All right reserved.

2. なぜ Event Sourcing 「良い」と思ったの？ State管理だと難しい？例え ...設置状況として「処理開始」「処理中」「処理完了」
…と管理すれできる ... ず！ (雑すぎるかもですが ...) 25 Copyright © 2025 Bitkey Inc. All right reserved.

2. なぜ Event Sourcing 「良い」と思ったの？ State管理だと難しい？でも... 設置状況：「処理中」
…ってどんな状況？ 26 Copyright © 2025 Bitkey Inc. All right reserved.

2. なぜ Event Sourcing 「良い」と思ったの？ State管理だと難しい？「処理中」がどんな状態を意味するかが実装に依存してしまう
でも... 設置状況：「処理中」そもそも「設置状況」と何？そうち処理 (実装)が …ってどんな状況？変わるかもしれない ... ステータスと乖離するかも ... 27 Copyright © 2025 Bitkey Inc. All right reserved.

2. なぜ Event Sourcing 「良い」と思ったの State管理だと難しい？「状態」？「処理状況」がどんな状態を表現するかがソースに
依存してしまう現実に存在しない「概念」設置状況：「処理中」そため移ろいやく …ってどんな状況？そもそも「設置状況」とそして壊れやすい何？そうち必要な処理 (実装)が変わるかもしれない ... ステータスと乖離するかも ... 28 Copyright © 2025 Bitkey Inc. All right reserved.

2. なぜ Event Sourcing 「良い」と思ったの？ State管理だと難しい？ State管理課題 (個人的な課題
) 1. 人によって認識仕方が異なる 2. 事業フェーズやドメイン理解が深まることによって、あるべき定義が変わりやすい 3. 状態 …上記根拠が「ソースコード」になり、変更されやすい特性がある「状態」を一次情報として管理するリスクが高い ... 29 Copyright © 2025 Bitkey Inc. All right reserved.

2. なぜ Event Sourcing 「良い」と思ったの？ State管理だと難しい？ State管理課題 (個人的な課題
) 1. 人によって認識仕方が異なるつまり、むずい 2. 事業フェーズやドメイン理解が深まることによって、あるべき定義が変わりやすい 3. 状態 …上記根拠が「ソースコード」になり、変更されやすい特性がある「状態」を一次情報として管理するリスクが高い ... 30 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ Event Sourcing を導入しようと思ったの Event Sourcing ※ かなり簡易化した図となっています 31
Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ Event Sourcing を導入しようと思ったの Event Sourcing カード登録コマンドを実行した ※
かなり簡易化した図となっています 32 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ Event Sourcing を導入しようと思ったの Event Sourcing カード登録コマンドを実行したカード登録
コマンドが成功した ※ かなり簡易化した図となっています 33 Copyright © 2025 Bitkey Inc. All right reserved.

1. なぜ Event Sourcing を導入しようと思ったの Event Sourcing カード登録コマンドを実行したカード登録
コマンドが成功したカード登録コマンドが失敗した ※ かなり簡易化した図となっています 34 Copyright © 2025 Bitkey Inc. All right reserved.

2. なぜ Event Sourcing 「良い」と思ったの？客観的に観測可能なカード登録コマンドを実行したカード登録
コマンドが成功したカード登録コマンドが失敗した具体的な「イベント」羅列や整理からモデリングを進めることができる 35 Copyright © 2025 Bitkey Inc. All right reserved.

2. なぜ Event Sourcing 「良い」と思ったの？客観的に観測可能なカード登録コマンドを実行した具体的な「イベント」
これが良かった！カード登録コマンドが成功したカード登録コマンドが失敗した羅列や整理からモデリングを進めることができる 36 Copyright © 2025 Bitkey Inc. All right reserved.

TypeScriptでの関数型モデリング、どう実践する？ “入居時オンボーディング”でやってみた実例の紹介〜良ったこと・大変だったこと〜株式会社ビットキー識名朝彬 2026/10/13
© 2025 Bitkey Inc.

⾃⼰紹介 2020.04 新卒Webエンジニアとしてキャリアスタート！⼩中学校で使われるクラウド型学習サービスをつくっていた識名朝彬(なっち) Tomoaki Shikina 2
2023.06 ビットキーへ参画 Now homehubの中核となる、デバイスとつながる部分やス Hobby homehubの賃貸領域の主にバックエンド開発に従事マートアクセスの部分にも領域を広げ、⽇々精進中サウナ王⼦近辺のサウナによく⾏きます童話式振り返り⾝の回りで起こった出来事を童話にして振り返り、学びを得ています Copyright © 2025 Bitkey Inc. All rights reserved.

2. 難しいポイントデバイスに対する通信を介する • 環境によって一発で成功するとは限らない • 時間「あけしめ」に関わることなので… •
必要に応じて、入居者や管理会社にアクったりもする入居者がアプリから操作する • 途中でタスクキルされたり... ションを促したい • 問題生じていそうなら、検知して対応したいしたい • 失敗してもそのまま放置したり... 41 Copyright © 2025 Bitkey Inc. All right reserved.

良ったこと / 大変だったこと良かったこと・ドメイン整理の議論しやすい / 変更時も開発者間での認識合わせやすい
・イベントソーシングにより実装も自然と関数型に寄り、嬉しさを享受でた大変だったこと・イベントと状態遷移の数膨らみ、実装も複雑に... ・ステートの表現にTypescriptのクラスを採用したことによるつらみ・Result型で、どういうエラー発生しうるの洞察は深まった ... 43 Copyright © 2025 Bitkey Inc. All right reserved.

4. 良ったこと ① ドメイン整理の議論しやすい／変更時も開発者間での認識合わせやすい「何が起きるんだっけ？」をベースに議論できた
• 『どういう状態ありうる』は抽象度高、発散しやすい。 • 一方で、『何起るんだっけ?』は具体的な出来事を列挙するため、開発者間やビジネスサイドとも認識を合わせやすい例：入居時オンボーディングでの整理 • 起こることの列挙と、その時どういう状態になる • 上記に対する対応を機能としてどう実現する？？を整理したことで、ビジネスサイドとも認識齟齬少な整理を進められた 45 Copyright © 2025 Bitkey Inc. All right reserved.

4. 良ったこと ① ドメイン整理の議論しやすい／変更時も開発者間での認識合わせやすい「何が起きるんだっけ？」をベースに議論できた
• 『どういう状態ありうる』は抽象度高、発散しやすい。 • 一方で、『何起るんだっけ?』は具体的な出来事を列挙するため、開発者間やビジネスサイドとも認識を合わせやすい例：入居時オンボーディングでの整理 • 起こることの列挙と、その時どういう状態になる • 上記に対する対応を機能としてどう実現する？？を整理したことで、ビジネスサイドとも認識齟齬少な整理を進められた 46 ※表現は一部変えてます Copyright © 2025 Bitkey Inc. All right reserved.

4. 良ったこと ① ドメイン整理の議論しやすい／変更時も開発者間での認識合わせやすい変更する時も同じ
• 「どういう出来事」がどこに新たに追加されるか？を中心に議論でき、認識ずれなく整理、実装を行えた例：新デバイスへの対応 • 親機と子機があり、それらが連携して動作するようなデバイスへ対応起こりうることとそれによる状態遷移を定義していたで、それに対してどこに何を追加するか？そ結果どうなるか？を認識合わせつつ進められた 47 Copyright © 2025 Bitkey Inc. All right reserved.

4. 良ったこと ② イベントソーシングにより実装も自然と関数型に寄り、嬉しさを享受で「起こったこと」を軸に、遷移関数を実装 • ある状態ら次の状態に遷移する関数を、イベントごとに1つ
• テストしやす、レビューの認知負荷も下げられた型で、状態ごとの「情報」と「操作」を定義 • 型のガードレールやエディタの補助を受けつつ開た状態持ちうる情報受け付けられる操作要求済み要求日時成功した／失敗した失敗失敗理由再試行する完了完了日時（なし）「失敗」状態だけほ失敗理由を持ち、「再試行」を受け付ける。の状態で再試行を呼ぼうとすると、コンパイル通らない発でた当時はまだエディタを使った開発メインだったので非常に助けられた 48 Copyright © 2025 Bitkey Inc. All right reserved.

5. 大変だったことイベントと状態遷移の数膨らみ、実装も複雑に… 出来事が増えると、状態と遷移も増える • 1つ1つの遷移関数は小さいままなので見やすい。 • しし、全体像は肥大化して実装では追いづら
すべてを大きなステートマシンなる中で扱わずより小さなサブセットに分割することで改善できそう例) 前の入居者の情報削除: イベント1, イベント2… 管理用の設定刷新: イベント3, イベント4… 50 Copyright © 2025 Bitkey Inc. All right reserved.

5. 大変だったことステートの表現に TypeScript のクラスを採用したことによるつらみ判定メソッドを抽象クラスに置いた • state. と打てば、判定もその状態だけ持つ操作も候補に出て
る • 当時はエディタ中心の開発だったので、この体験を優先した関数にすると名前をある程度覚えて import しないと辿れない... 問題点: 親と子が互いに型参照し、ファイル分割できない • 親は this is XxxState で子を参照し、子は extends で親を参照する...(よ • ない) その結果状態と遷移すべて1ファイルに。一つ一つの遷移ロジックは小さいファイルは大なり、全体像掴みづらい // 親 -> 子：判定の戻り値の型で、子を参照 abstract class StateAbstract { isStarted = (): this is StartedState => ... isCompleted = (): this is CompletedState => ... } // 子 -> 親：extends で、親を参照 class StartedState extends StateAbstract { ... } class CompletedState extends StateAbstract { ... } keyExchange. // isKeyExchangeStarted() isKeyPairFullyUpdatedOnBkp() ... 判定が候補に出る if (keyExchange.isKeyPairFullyUpdatedOnBkp()) { keyExchange. // 型で絞られた候補だけ出てくる fullyUpdatedHoles getUpdatedOnBkpAndNotUpdatedOnDeviceHoles() } 51 Copyright © 2025 Bitkey Inc. All right reserved.

5. 大変だったこと Result型で、どういうエラー発生しうるの洞察は深まった • 当初、欲しいのはただのOK / NGを表すバリアントだと考えていたので、自作Result型を作成して対応
• しかし当然ながら、合成が右 ... const loaded = await this.loadAndValidate(param); if (loaded.error) return ResultUtil.failure(loaded.error); const started = await this.startKeyExchangeIfNeed({...}); if (started.error) return ResultUtil.failure(started.error); ようにかなり冗長に... const targets = await this.detectRedeliverTargets({...}); if (targets.error) return ResultUtil.failure(targets.error); 自作Resultに必要に応じてandThenなどを用意しつつ、重くなってきたらneverthrowなどライブラリを導入する良さそう const checked = await this.dep.checkDelivered.handle({...}); if (checked.error) return ResultUtil.failure(checked.error); が …… return ResultUtil.success(state); 52 Copyright © 2025 Bitkey Inc. All right reserved.

関数型ドメインモデリングの理想と現実 / Domain Modeling Made Funct...

関数型ドメインモデリングの理想と現実 / Domain Modeling Made Functional: Ideals vs. Reality

More Decks by 株式会社ビットキー / Bitkey Inc.

Other Decks in Technology

Featured

Transcript