Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Domain Modeling The Cycle Frontier
Search
iida-hayato
July 10, 2022
Programming
0
97
Domain Modeling The Cycle Frontier
iida-hayato
July 10, 2022
Tweet
Share
More Decks by iida-hayato
See All by iida-hayato
The Cycle Frontier をネタにドメインモデルの話をする
iidahayato
0
81
iosと絵文字問題
iidahayato
0
920
Other Decks in Programming
See All in Programming
o1モデルのプロンプトエンジニアリングって?
ktc_wada
0
380
CSC305 Lecture 01
javiergs
PRO
0
110
Android開発以外のAndroid開発経験の活かしどころ
konifar
2
1.2k
How to Break into Reading Open Source
kaspth
2
230
Shinjuku.rb#95:心の技術書紹介
free_world21
1
110
Perl 5 OOP機構30年史 - Perl 5's OOP Mechanism over the past 30 years
moznion
1
530
Debugging: All you need to know (English Only)
jmatsu
0
110
Делим тесты между QA и разработчиком
mariyasaygina
0
190
Composing an API the *right* way (Droidcon New York 2024)
zsmb
2
420
M5Stackボードの選び方
tanakamasayuki
0
110
GraphQLの魅力を引き出すAndroidクライアント実装
morux2
3
1.1k
So you want to write a User-Defined Function for Flink? @ Current 2024 - Austin, TX
hpgrahsl
0
100
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
64
11k
Embracing the Ebb and Flow
colly
83
4.4k
A Philosophy of Restraint
colly
202
16k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
Optimising Largest Contentful Paint
csswizardry
31
2.8k
Testing 201, or: Great Expectations
jmmastey
36
7k
Scaling GitHub
holman
458
140k
How to Ace a Technical Interview
jacobian
274
23k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
109
6.9k
Writing Fast Ruby
sferik
623
60k
The Cost Of JavaScript in 2023
addyosmani
42
5.7k
Mobile First: as difficult as doing things right
swwweet
221
8.8k
Transcript
The Cycle Frontier をネタに ドメインモデルの話をする
The Cycle Frontier という超面白いゲームがリリースされまし た - 基本無料のFPS - タルコフをカジュアルにしたようなゲームといえば分かる人はわかる
The Cycle Frontierの説明 - 宇宙ステーションと惑星上を行き来しながらタスクをすすめるゲーム - 宇宙ステーションでやること - 武器や消耗品の売買 -
装備を整えて地表に降り立つ - 地表でやること - 探索してアイテムを漁ったり - 他のプレイヤーと戦ったり - 脱出船を呼んで無事宇宙ステーションに帰ることが目的
多数のバグを見てきたので紹介しつつどう改善すればいいか 考えよう - アルファテストから参加していろいろバグを見てきた - ドメインモデルの例としてちょうど良さそうなので紹介
倉庫溢れバグ - 持ち帰ったり購入したアイテムを入れておくための倉庫(Stash)と地表に持っていく ためのカバン(Bag)がある - 同種のアイテムはアイテムごとに決められた数までまとめて1スタックとして数える - 回復薬は5個 - 鉱石は10個
- 倉庫には上限のスタックがある - マイクラのインベントリと同じと思って OK
倉庫溢れバグ:ログインボーナス - ログイン時にアイテムを1個もらえることがある - 倉庫が満杯のときにも受け取りに成功する - 倉庫が上限を突破する
倉庫溢れバグ:サプライボックス - 24時間ごとに4~8個のアイテムを受け取れる機能 - 倉庫が満杯のときに受け取ろうとすると倉庫がいっぱいで受け取りに失敗する - 倉庫を4つ空きスタック作って受け取る - アイテムがいくつで合っても受け取りに成功する -
倉庫が上限を突破する
倉庫溢れバグ:買い物 - 買い物で手に入ったアイテムは倉庫へ入る - 仮に倉庫の空きが1スタックある状態で - 回復薬(最大5個までスタック)を5個購入する - 倉庫の上限で購入に失敗する -
回復薬を1個を5回にわけて購入する - 購入に成功する
倉庫溢れバグ:買い物 - 再現方法不明 - アイテムを上限を超えていくらでも買える状態になることがある - 一度上限突破するといくらでも買える???
バグらないパターン - カバンと倉庫の間のアイテム移動をするときは適切に動作しているように見える
なんでこんなことになってるか想像する - バグの挙動に全然一貫性がない - それぞれの処理が全く共通化されずに個別の実装になっていそう - 多分ユニットテストもない
どう改善するか - それぞれのロジック(買い物とかログインボーナスとか)のバグを個別の問題と捉え てしっかりテストを書いて直しましょう - という考えもありだが - もうちょっと一貫性があって保守しやすい形にしたい - 今後もログボのような処理
,や買い物のような処理など増える可能性がある
オブジェクト指向的な解決 - 倉庫クラスみたいなものを作って - 倉庫が満たすべき制約は倉庫にチェックさせる - 制約がダメだったなら失敗で返す - 買い物やログボの処理の中では倉庫にアイテムを追加するコードだけを書く -
`倉庫.アイテム追加(回復薬5個)` みたいな - それぞれの処理では倉庫が満たすべき条件は知らないようにする
オブジェクト指向的な解決 - とすることで - 倉庫の仕様についてのバグは倉庫クラスのバグと切り分けができる - 今後新たな買い物ロジックが増えたとしても倉庫の挙動は守られる - といったメリットが期待できる
オブジェクト指向的な解決 - この倉庫クラスのようなものを「ドメインモデル」 - 買い物やログボの処理を配置するやつらを「UseCase」や「アプリケーションサービ ス」 - ドメインを利用するというニュアンスで「ドメインモデルのクライアント」と書かれてることもある - と呼びます
オブジェクト指向的な解決 - 逆に当初のように,ドメインモデルを用意せず - 倉庫の制約管理を各買い物ロジック,ログボロジックにそれぞれつらつら書いている コードを - 「トランザクションスクリプト」と呼びます - この場合「倉庫」はおそらく単なる配列か
HashMap
Topic - コードの寿命 - 倉庫がどんな仕様であるか(ドメインモデル),とどういうときに倉庫にアイテムを追加 するか(UseCase)では前者のほうが仕様の寿命が長いことを期待できる
Topic - 問い合わせるな命令せよ - UseCaseからは倉庫がどういう状態であるかは関知しない - とりあえずアイテムを追加してみて成功するか失敗するかを見る - 逆にUseCaseが「倉庫にアイテムがいくつ入ってるかな?」みたいなことを気にしだ すと,倉庫クラスに入れたいロジックが漏れ出すことになる
Topic - ドメインモデル貧血症とは - 今までの話と逆に,倉庫の制約条件のロジックを全部UseCase側に持っていき,倉 庫クラスはただの配列やデータの入れ物として使う状態を考える - つまり当初の問題点を再現した状態 - ただ倉庫クラスのコードが増えただけ
- 悪いところどり状態 - ドメインモデルから重要なロジックが漏れ出た状態のためこれをドメイン貧血症と呼 ぶ
Topic - トランザクションスクリプトで十分なケース - 倉庫のドメインモデルは複数のUseCaseから利用される - 仮に倉庫を更新するケースが1つしか無いならわざわざドメインモデルを作る必要 性は少ないかもしれない - 例えばマスタ管理画面とか
境界づけられたコンテキスト - 宇宙ステーションで扱う「カバン」と惑星上で扱う「カバン」は同じものなのか問題 - 「カバンからアイテムを捨てる」という行為は惑星上でしかできない - 「カバンから倉庫へアイテムを移動する」「倉庫からカバンへアイテムを移動する」と いう行為は宇宙ステーションでしかできない - 概念が似てるものでコードの内容もほとんど一緒だけど実は偶然コードが一緒に
なってるだけなのでは - しかし両方「カバン」と呼ばれている - コードだけ見てもどこで分割するものか判断できない
境界づけられたコンテキスト - 仕様全体を分析してコンテキストで分割する - 例えば宇宙ステーション ,惑星上でわける - これを「境界づけられたコンテキスト」と呼ぶ - それぞれの境界づけられたコンテキストの中に方言のようにモノの名前をつける
- 宇宙ステーションのなかでのカバンと惑星上でのカバンという言い方ができる - それぞれの中では「カバン」と呼んで良い - この方言を「ユビキタス言語」という - もちろん仕様を分析した結果このようになったという前提 - 境界づけられたコンテキストに沿ってコードをいい感じに分割したうえでユビキタス 言語を使ってコードを書きましょう - とすることで前述の問題を解決できる - コードどころかサービスごと分割してしまおうというのがマイクロサービスの考え
境界づけられたコンテキスト - 境界づけられたコンテキストに沿ってコードをいい感じに分割したうえでユビキタス 言語を使ってコードを書きましょう - とすることで前述の問題を解決しつつ問題空間を小さくするのが DDDのやりたいことの一つ - コードどころかサービスごと分割してしまおうというのがマイクロサービスの考え方 -
Cycleも宇宙ステーションと惑星上でインスタンスが別っぽい - レイテンシなどのアーキテクチャ特性が全然違う - 実際に境界づけられたコンテキストの間でマイクロサービスとしてわけるかどうかはアーキテクチャ 特性やアーキテクチャ量子次第
終わりに - 他にもDDDの話題を見いだせそうな気がするのでもうちょっとこすって資料を増や したい - Webシステムの話なのかUnrealEngineの話なのかに影響するところは取り除いた - ここからドメインモデルをどう永続化するか,どうユーザーインターフェースに反映さ せるかはまた一大トピック -
The Cycle Frontier 面白いのでみんなもやろう