大規模Unityゲーム開発の設計事例〜ドメイン駆動設計とDIコンテナを導入した一年を振り返る〜
CEDEC 2021での株式会社アプリボットによる講演．
開発スピードとメンテナンス性の両立が重要．
設計が重要
多人数の開発では自己流の設計が発生する．
チーム内での思想の統一・実績のある体系化された仕組みが必要．
EasyとSimpleが重要
Easy: 手数が少ないが覚えることが多く，特定の状況に強いが他には弱い設計．
Simple: 覚えることが少ないが，手数が増えたり，自分で組み合わせる必要がある．
ドメイン駆動設計がSimpleだと判断．
ゲームにも適用可能．
ドメイン駆動開発
エンジニアがドメインをよく理解する必要があるという点でドメイン駆動設計に親和する．
データ中心のプロダクトや小規模なプロダクトには向かない．
複雑性のある，継続的に手が入るプロダクトに向く．
高速化が必要な部分には適用ができない．
高速化が必要になる部分はECSのような棲み分けが必要になる．
グラフィック，物理演算，サウンド，AI
参考書籍
エリック・エヴァンスのドメイン駆動設計
Domain-Driven Design Quickly
ドメイン駆動設計入門
Domain-Driven Design Reference
オブジェクト指向入門 第2版 原則・コンセプト
ゲームが表現しようとしている対象領域(ドメイン)とは？
システムを構成する要素から，汎用的な部分を抜いて残る部分．
成長ロジック，ダメージ計算，キャラ性能．
ユビキタス言語の対応表を作る．
MonoBehaviourだからといってユーザインターフェース
DIコンテナはZenjectを利用しているが，DIコンテナとして汎用的な機能だけを利用し依存しないよう注意．
シーン読み込み直後の初期化の際にDIコンテナに詰めて取得するだけ．
初期化以後に動的に生成されるインスタンスやprefabには注入しない．
ドメインに対するテストはUnity Test Runnerで実行．
契約プログラミング
とにかく単体で動くように作る．
prefabへのアクセスはroot要素を経由する．
Facadeを参考にした運用．
UIのButtonの効果音など
トロフィー獲得などはObserverを用いて実現．
失敗
内部が変化しないものはエンティティとして実装しなくて良い．
ドメインモデル貧血症
集約の境界が曖昧でFacadeに失敗する．
がんばる．
状態を外から参照するだけならokという運用にしている．
悩み
Valueの実装がだるい．
Recordsで解決できそう．
asRagi.icon
プロダクトマネジメント的な視点がある．
なぜドメイン駆動開発が必要なのかということに，思想の統一という明確な理由がある．
Simple/Easy軸の思考はなるほどという感じだった．
それはそれとしてドメイン駆動設計が一通り頭に入っている人向けだと感じた．
Equals()とGetHashCode()の実装の必要性はそうではなくない？と思った．
ドメイン駆動設計を示した優れた書籍は多数存在するが，それをゲームに適用した例は少ないので貴重な資料だと感じる．
参考書籍がバシッと示されていて参考になった．
メモリアロケーションはどうするんだろという気持ちになった．
ゲームにおいてはドメインエキスパートがドメインをよくわかっていないという状況もあるので，難しい．
#CEDEC