ドメインモデリング実践ガイド：イミュータブルモデルとDeciderパターンで実現する堅牢な設計
お疲れ様です！IT業界で働くアライグマです！
先日、私のチームで運用していた受注管理システムで、状態遷移のバグが本番障害を引き起こすという事態が発生しました。原因を調査したところ、ドメインモデルが可変（ミュータブル）であったため、複数の処理が同時に状態を変更し、不整合が生じていたのです。
この経験から、私たちはイミュータブルモデルとDeciderパターンを導入し、ドメインロジックを根本から見直しました。結果として、同様のバグは完全に解消され、テストの書きやすさも大幅に向上しました。
この記事では、永続化と切り離した「純粋な」ドメインモデリングの考え方と、イミュータブルモデル・Deciderパターンを使った堅牢な設計手法を解説します。私のチームでの実践経験をもとに、再現性のある設計パターンをお伝えします。
従来のドメインモデリングの課題
ドメインモデリングは、ビジネスロジックをコードで表現するための重要な設計手法です。しかし、従来のアプローチにはいくつかの課題がありました。
アネミックドメインモデルの問題
多くのプロジェクトで見られる「アネミックドメインモデル」は、データの入れ物としてのエンティティと、ロジックを持つサービスクラスが分離した構造です。
- ロジックの分散：ビジネスルールがサービス層に散らばり、どこに何があるかわかりにくい
- 状態の不整合：エンティティの状態を外部から自由に変更できるため、不正な状態遷移が起きやすい
- テストの困難さ：サービスクラスのテストにはモックが多数必要になり、テストが複雑化する
私のチームでも、当初はこのアプローチを採用していました。しかし、システムが複雑化するにつれて、バグの発生頻度が増加し、新機能の追加にも時間がかかるようになりました。
ドメインモデリングの基礎を学ぶなら、ドメイン駆動設計が参考になります。ドメインモデルを中心に据えた設計の本質を理解するための必読書です。
設計パターンの基礎については、FastAPI + LangChain実践ガイド：高速AIバックエンド構築の設計パターンと運用ノウハウも参考になります。
イミュータブルモデルの基本概念
イミュータブルモデルは、一度作成したオブジェクトの状態を変更しない設計パターンです。状態を変更する代わりに、新しい状態を持つ新しいオブジェクトを生成します。
イミュータブルモデルの利点
イミュータブルモデルを採用することで、以下の利点が得られます。
- スレッドセーフ：状態が変更されないため、並行処理でも安全に扱える
- 予測可能性：オブジェクトの状態が変わらないため、デバッグが容易
- 履歴の追跡：状態変更のたびに新しいオブジェクトが生成されるため、変更履歴を自然に保持できる
TypeScriptでの実装例
以下は、受注エンティティをイミュータブルに設計した例です。
// イミュータブルな受注エンティティ
type OrderStatus = 'pending' | 'confirmed' | 'shipped' | 'delivered';
interface Order {
readonly id: string;
readonly customerId: string;
readonly items: ReadonlyArray<OrderItem>;
readonly status: OrderStatus;
readonly createdAt: Date;
readonly updatedAt: Date;
}
// 状態変更は新しいオブジェクトを返す
function confirmOrder(order: Order): Order {
if (order.status !== 'pending') {
throw new Error('Only pending orders can be confirmed');
}
return {
...order,
status: 'confirmed',
updatedAt: new Date()
};
}この設計では、confirmOrder関数は元のorderオブジェクトを変更せず、新しいオブジェクトを返します。これにより、状態遷移のルールがコード上で明確になります。
クリーンアーキテクチャの観点からは、Clean Architecture 達人に学ぶソフトウェアの構造と設計が参考になります。ドメインモデルを中心に据えた設計の考え方が詳しく解説されています。
マイクロサービスでのドメインモデリングについては、LLM Council実践ガイド：複数AIモデルの合議システムで実現する高精度判断の設計パターンも参考になります。
Deciderパターンの導入
Deciderパターンは、状態（State）・イベント（Event）・決定（Decide）の3つの要素でドメインロジックを構造化する設計パターンです。
Deciderパターンの構成要素
Deciderパターンは以下の3つの要素で構成されます。
- State（状態）：現在のドメインの状態を表すイミュータブルなオブジェクト
- Event（イベント）：状態変更のきっかけとなる出来事を表すオブジェクト
- Decide（決定）：現在の状態とコマンドから、発生するイベントを決定する純粋関数
ドメインモデリング手法の比較
私のチームで各手法を評価した結果、以下のような傾向が見られました。
- Deciderパターンが最も高い保守性：状態遷移が純粋関数で表現されるため、テストが容易
- イミュータブルモデルも高スコア：状態の不変性により、バグの発生を抑制
- アネミックモデルは低スコア：ロジックの分散により、保守が困難になりやすい
TypeScriptでのDecider実装
以下は、受注ドメインにDeciderパターンを適用した例です。
// イベント定義
type OrderEvent =
| { type: 'OrderCreated'; orderId: string; customerId: string }
| { type: 'OrderConfirmed'; orderId: string }
| { type: 'OrderShipped'; orderId: string };
// コマンド定義
type OrderCommand =
| { type: 'CreateOrder'; customerId: string; items: OrderItem[] }
| { type: 'ConfirmOrder' }
| { type: 'ShipOrder' };
// Decider関数（純粋関数）
function decide(state: Order | null, command: OrderCommand): OrderEvent[] {
switch (command.type) {
case 'CreateOrder':
if (state !== null) {
throw new Error('Order already exists');
}
return [{ type: 'OrderCreated', orderId: generateId(), customerId: command.customerId }];
case 'ConfirmOrder':
if (state?.status !== 'pending') {
throw new Error('Only pending orders can be confirmed');
}
return [{ type: 'OrderConfirmed', orderId: state.id }];
case 'ShipOrder':
if (state?.status !== 'confirmed') {
throw new Error('Only confirmed orders can be shipped');
}
return [{ type: 'OrderShipped', orderId: state.id }];
}
}この設計の特徴は、decide関数が純粋関数であることです。同じ入力に対して常に同じ出力を返すため、テストが非常に書きやすくなります。
TDDの観点からは、テスト駆動開発が参考になります。純粋関数を中心とした設計は、テストファーストな開発との相性が非常に良いです。
イベントソーシングについては、Polars実践ガイド：Pandasから移行して大規模データ処理を10倍高速化する設計パターンも参考になります。
実践的な導入ステップ
イミュータブルモデルとDeciderパターンを既存プロジェクトに導入する際の、実践的なステップを紹介します。
段階的な移行アプローチ
既存のコードベースを一度に書き換えるのは現実的ではありません。以下のステップで段階的に移行することをおすすめします。
- Step 1：新規機能からイミュータブルモデルを採用する
- Step 2：バグが多発している箇所をDeciderパターンでリファクタリング
- Step 3：テストカバレッジを上げながら、既存コードを順次移行
ケーススタディ：受注管理システムの改善
私のチームでの実践例を紹介します。
Before（改善前）
- 受注エンティティは可変（ミュータブル）で、サービス層から直接状態を変更
- 状態遷移のルールがサービス層に散在し、把握が困難
- 月平均5件の状態遷移バグが発生
Action（改善内容）
- 受注エンティティをイミュータブルに再設計
- 状態遷移ロジックをDeciderパターンで集約
- 各状態遷移に対するユニットテストを追加（カバレッジ95%）
After（改善後）
- 状態遷移バグは0件に減少（3ヶ月間）
- 新機能の追加時間が平均40%短縮
- コードレビューの指摘事項が60%減少
ソフトウェア設計の原則を体系的に学ぶなら、ソフトウェアアーキテクチャの基礎が参考になります。アーキテクチャの基礎から応用まで幅広くカバーしています。
TypeScriptでの実践については、Deno 2.3実践ガイド：ローカルNPMパッケージ対応で実現するモダンTypeScript開発も参考になります。
まとめ
イミュータブルモデルとDeciderパターンは、堅牢なドメインモデリングを実現するための強力な設計手法です。
この記事で紹介したポイントを整理すると、以下の通りです。
- イミュータブルモデルの利点：スレッドセーフ、予測可能性、履歴追跡が容易
- Deciderパターンの構成：State・Event・Decideの3要素で状態遷移を構造化
- 純粋関数の活用：テストが書きやすく、バグの発生を抑制
- 段階的な導入：新規機能から始め、既存コードを順次移行
私のチームでは、この設計パターンを導入してから、状態遷移に起因するバグがゼロになりました。最初は学習コストがかかりますが、長期的には保守性の向上とバグの削減により、大きなリターンが得られます。
まずは小さな機能からイミュータブルモデルを試してみてください。純粋関数の書きやすさとテストのしやすさを実感できるはずです。
厳しめIT女子 アラ美による解説ショート動画はこちら
PjMが厳選した【高年収】への近道
