Domain Modeling The Cycle Frontier

Transcript

1. The Cycle Frontier をネタに ドメインモデルの話をする
2. The Cycle Frontier という超面白いゲームがリリースされまし た - 基本無料のFPS - タルコフをカジュアルにしたようなゲームといえば分かる人はわかる
3. The Cycle Frontierの説明 - 宇宙ステーションと惑星上を行き来しながらタスクをすすめるゲーム - 宇宙ステーションでやること - 武器や消耗品の売買 - 装備を整えて地表に降り立つ - 地表でやること - 探索してアイテムを漁ったり - 他のプレイヤーと戦ったり - 脱出船を呼んで無事宇宙ステーションに帰ることが目的
4. 多数のバグを見てきたので紹介しつつどう改善すればいいか 考えよう - アルファテストから参加していろいろバグを見てきた - ドメインモデルの例としてちょうど良さそうなので紹介
5. 倉庫溢れバグ - 持ち帰ったり購入したアイテムを入れておくための倉庫(Stash)と地表に持っていく ためのカバン(Bag)がある - 同種のアイテムはアイテムごとに決められた数までまとめて1スタックとして数える - 回復薬は5個 - 鉱石は10個 - 倉庫には上限のスタックがある - マイクラのインベントリと同じと思って OK
6. 倉庫溢れバグ:ログインボーナス - ログイン時にアイテムを1個もらえることがある - 倉庫が満杯のときにも受け取りに成功する - 倉庫が上限を突破する
7. 倉庫溢れバグ:サプライボックス - 24時間ごとに4~8個のアイテムを受け取れる機能 - 倉庫が満杯のときに受け取ろうとすると倉庫がいっぱいで受け取りに失敗する - 倉庫を4つ空きスタック作って受け取る - アイテムがいくつで合っても受け取りに成功する - 倉庫が上限を突破する
8. 倉庫溢れバグ:買い物 - 買い物で手に入ったアイテムは倉庫へ入る - 仮に倉庫の空きが1スタックある状態で - 回復薬(最大5個までスタック)を5個購入する - 倉庫の上限で購入に失敗する - 回復薬を1個を5回にわけて購入する - 購入に成功する
9. 倉庫溢れバグ:買い物 - 再現方法不明 - アイテムを上限を超えていくらでも買える状態になることがある - 一度上限突破するといくらでも買える???
10. バグらないパターン - カバンと倉庫の間のアイテム移動をするときは適切に動作しているように見える
11. なんでこんなことになってるか想像する - バグの挙動に全然一貫性がない - それぞれの処理が全く共通化されずに個別の実装になっていそう - 多分ユニットテストもない
12. どう改善するか - それぞれのロジック(買い物とかログインボーナスとか)のバグを個別の問題と捉え てしっかりテストを書いて直しましょう - という考えもありだが - もうちょっと一貫性があって保守しやすい形にしたい - 今後もログボのような処理 ,や買い物のような処理など増える可能性がある
13. オブジェクト指向的な解決 - 倉庫クラスみたいなものを作って - 倉庫が満たすべき制約は倉庫にチェックさせる - 制約がダメだったなら失敗で返す - 買い物やログボの処理の中では倉庫にアイテムを追加するコードだけを書く - `倉庫.アイテム追加(回復薬5個)` みたいな - それぞれの処理では倉庫が満たすべき条件は知らないようにする
14. オブジェクト指向的な解決 - とすることで - 倉庫の仕様についてのバグは倉庫クラスのバグと切り分けができる - 今後新たな買い物ロジックが増えたとしても倉庫の挙動は守られる - といったメリットが期待できる
15. オブジェクト指向的な解決 - この倉庫クラスのようなものを「ドメインモデル」 - 買い物やログボの処理を配置するやつらを「UseCase」や「アプリケーションサービ ス」 - ドメインを利用するというニュアンスで「ドメインモデルのクライアント」と書かれてることもある - と呼びます
16. オブジェクト指向的な解決 - 逆に当初のように,ドメインモデルを用意せず - 倉庫の制約管理を各買い物ロジック,ログボロジックにそれぞれつらつら書いている コードを - 「トランザクションスクリプト」と呼びます - この場合「倉庫」はおそらく単なる配列か HashMap
17. Topic - コードの寿命 - 倉庫がどんな仕様であるか(ドメインモデル),とどういうときに倉庫にアイテムを追加 するか(UseCase)では前者のほうが仕様の寿命が長いことを期待できる
18. Topic - 問い合わせるな命令せよ - UseCaseからは倉庫がどういう状態であるかは関知しない - とりあえずアイテムを追加してみて成功するか失敗するかを見る - 逆にUseCaseが「倉庫にアイテムがいくつ入ってるかな?」みたいなことを気にしだ すと,倉庫クラスに入れたいロジックが漏れ出すことになる
19. Topic - ドメインモデル貧血症とは - 今までの話と逆に,倉庫の制約条件のロジックを全部UseCase側に持っていき,倉 庫クラスはただの配列やデータの入れ物として使う状態を考える - つまり当初の問題点を再現した状態 - ただ倉庫クラスのコードが増えただけ - 悪いところどり状態 - ドメインモデルから重要なロジックが漏れ出た状態のためこれをドメイン貧血症と呼 ぶ
20. Topic - トランザクションスクリプトで十分なケース - 倉庫のドメインモデルは複数のUseCaseから利用される - 仮に倉庫を更新するケースが1つしか無いならわざわざドメインモデルを作る必要 性は少ないかもしれない - 例えばマスタ管理画面とか
21. 境界づけられたコンテキスト - 宇宙ステーションで扱う「カバン」と惑星上で扱う「カバン」は同じものなのか問題 - 「カバンからアイテムを捨てる」という行為は惑星上でしかできない - 「カバンから倉庫へアイテムを移動する」「倉庫からカバンへアイテムを移動する」と いう行為は宇宙ステーションでしかできない - 概念が似てるものでコードの内容もほとんど一緒だけど実は偶然コードが一緒に なってるだけなのでは - しかし両方「カバン」と呼ばれている - コードだけ見てもどこで分割するものか判断できない
22. 境界づけられたコンテキスト - 仕様全体を分析してコンテキストで分割する - 例えば宇宙ステーション ,惑星上でわける - これを「境界づけられたコンテキスト」と呼ぶ - それぞれの境界づけられたコンテキストの中に方言のようにモノの名前をつける - 宇宙ステーションのなかでのカバンと惑星上でのカバンという言い方ができる - それぞれの中では「カバン」と呼んで良い - この方言を「ユビキタス言語」という - もちろん仕様を分析した結果このようになったという前提 - 境界づけられたコンテキストに沿ってコードをいい感じに分割したうえでユビキタス 言語を使ってコードを書きましょう - とすることで前述の問題を解決できる - コードどころかサービスごと分割してしまおうというのがマイクロサービスの考え
23. 境界づけられたコンテキスト - 境界づけられたコンテキストに沿ってコードをいい感じに分割したうえでユビキタス 言語を使ってコードを書きましょう - とすることで前述の問題を解決しつつ問題空間を小さくするのが DDDのやりたいことの一つ - コードどころかサービスごと分割してしまおうというのがマイクロサービスの考え方 - Cycleも宇宙ステーションと惑星上でインスタンスが別っぽい - レイテンシなどのアーキテクチャ特性が全然違う - 実際に境界づけられたコンテキストの間でマイクロサービスとしてわけるかどうかはアーキテクチャ 特性やアーキテクチャ量子次第
24. 終わりに - 他にもDDDの話題を見いだせそうな気がするのでもうちょっとこすって資料を増や したい - Webシステムの話なのかUnrealEngineの話なのかに影響するところは取り除いた - ここからドメインモデルをどう永続化するか,どうユーザーインターフェースに反映さ せるかはまた一大トピック - The Cycle Frontier 面白いのでみんなもやろう