TECH×GAME COLLEGE#28で軽量DDDに関する発表をさせていただきました
お久しぶりのブログでこんにちは、ナカエです。
TECH×GAME COLLEGE主催のテクロス様からお誘いをいただいて、10/23に開催されたTECH×GAME COLLEGE#28に登壇させていただきました。
関連資料・記事
発表したスライドはこちら
形から入ったドメイン駆動設計によるゲーム開発の光と闇 - Specker Deck
ログミーTechの記事
登壇内容を記事にしていただいています。
概要
「形から入ったドメイン駆動設計によるゲーム開発の光と闇」と題して、 軽量DDDをテーマに実際のゲーム開発プロジェクトでの成功と失敗について語っています。
戦術面だけをつまみ食いする軽量DDDはDDDの本質ではないと指摘されることも多いですが、 設計への入り口にはなっており、形から入るのも悪いことばかりではなかったということを実例を交えつつ紹介しました。 50分と長めの時間をいただいたのですがいろいろと詰め込みすぎてだいぶ駆け足です。
発表後は懇親会かな？と思っていたのですが、そのままパネルディスカッションに突入する盛りだくさんの内容でした。
発表の補足
資料作りのためにとあるプロジェクトのSlackを読み返していたのですが、思い入れがありすぎてあれもこれもと詰め込んだ結果、スライドが120枚くらいに膨らんでいました。 ボリューム調整のために泣く泣く削った話や補足を書いておこうと思います。
ガチャの話
ガチャのチューニングの話には実は第二章がありました。 ガチャを10万回シミュレーションして提供割合に問題がないかを確認するガチャシミュレータの機能。10連ガチャですら苦労したのに10万回？ 正気だろうかと。 スライドにあった第一段階のチューニングが終わったあたりで、1万回ほど回すと推定36分ほどとなることがわかりました。 軽く概算してみると、仕様書で指定されたロジックそのままでは一部の処理が168億回ほど実行される計算量になっていました。
結果が等価になるアルゴリズムを提案して1試行ごとの処理が減るように仕様を修正、90秒まで減らしています。 クエリの発行をRepositoryのみに抑えているので、DBを気にすることなく改善に持ち込めました。
Application ServiceとDomain Service
このプロジェクトではユースケースであるApplication Serviceとドメインの機能であるDomain Serviceが混在する傾向があり、資料でも一部混ざった表現になっている箇所があります。 フレームワークのControolerでジャイアントロックを取るケースなどもあり、本来のApplication Serviceの役目と1対1にはなるクラスが厳密にははない状態でした。 Serviceという概念が広すぎるので、次は命名を変えた方が良さそうだと反省をしています。たとえばUseCaseとDomainServiceなど。
発表後
勉強会後は勉強会に参加してくれた東京の若人たちと飲みに行きました。設計や開発についてなかなか話の尽きない楽しい時間でした。
まとめ
個人的にもここ2〜3年くらい溜めていた思考をアウトプットする絶好の機会とさせていただきました。登壇の機会をいただき本当にありがとうございました。
