ドメイン駆動設計(DDD) - CASru-GAME/TeamGameDevBootcamp GitHub Wiki
ドメイン駆動設計
ドメインとは
- 解決しようとしている問題領域
- ゲーム制作に置き換えると、ゲーム独自の概念・ルール・仕様
ドメインエキスパート
- 対象とする領域の専門家、ゲームではディレクターやプランナー
ユビキスタス言語
- 開発者とドメインエキスパートの両方がわかる言葉
- 使用する言葉を統一し同じ意味の別の単語を使わないようにする。(スキル、アビリティなど)
- つまり使う言葉を統一しようということ
- 勘違いや表記ゆれの問題を防ぐ
ドメイン駆動設計に使用されるパターンの例
値オブジェクト
- お金などの値をint型ではなくMoneyといった値オブジェクトとして扱う。
- 一度生成されたら中身は不変
- 中身が同じなら等価として扱う
メリット
- 変更を防ぎ、安全に共有・参照渡しができる。
- バリデーションにより不正な値が入ることを防ぐ
エンティティ
- ユーザー情報など生成された後、中身が変化するもの。
- 中身が変化した後も同一のものとして扱うためidを持つ。
メリット
- idによって中身が同じものとも区別できる
サービス
- ものとして扱えないものは値オブジェクトやエンティティを扱うサービスとして実装する。
集約
- 関連するオブジェクトの集まり。
- データを変更するときの窓口となりここを通さないアクセスは認めない。
メリット
- データが一か所にまとまりわかりやすい
- ひとつの塊として扱うため、カプセル化できる。
リポジトリ
- データの読み出し・保存を行う。
- データベースにアクセスするのはここだけ
メリット
- データ操作をカプセル化できる。
- データベースを意識せずにデータを扱える。
境界付けられたコンテキスト
- 同じ概念に対して複数のモデルができた場合、境界を明示することにより、協会内で独立して開発を行う。
- ほかの箇所との結合度を減らすことにつながる。
レイヤードアーキテクチャ
インフラストラクチャー層
- 通信機能
- データベース操作
- リポジトリの実装
ユーザーインターフェース層(プレゼンテーション層)
- UIの表示
- ユーザーに見える部分
アプリケーション層
- ドメインオブジェクト・基盤機能を使いアプリケーション全体の調整・進行を行う。
- キャラクター情報の管理や装備の変更といったバックエンドの処理
ドメイン層
- 値オブジェクト
- エンティティ
- たぶんいろんなとこで使うクラスとか置いとくところ
- ほかのレイヤーと隔離されていることが重要
依存関係逆転の原則
- 下層から上層へのアクセスは禁止
- 下から上にアクセスしたいときはアクセス可能な同じ階層にinterfaceを用意し、アクセスする。
- 実態であるViewを利用するときはDIコンテナを使用。