6/11に「JJUG ナイトセミナー 6.11 ドメイン駆動設計特集！」に行ってきました。２回に分けてセミナーの内容を紹介します。
【東京】JJUG ナイトセミナー 「6.11 ドメイン駆動設計特集！ 」 - 日本Javaユーザーグループ | Doorkeeper
今回は２回目です。２つ目のセッションは、グリー株式会社 加藤 潤一さんの「DDDを実践する時に役に立つ話し」でした。
セッション内容
事例（GREEチャット）
- 企画：昨年10月から8カ月間
- チームメンバー：8人
- 言語：Scala
- 設計手法：DDD
- プロセス：Scrum
- 規模
- サブドメイン：3
- モジュール：17
プロジェクトが始まる前
- ３日でプロトタイプを書いてみた
- Scala/Finagle使用
- ドメイン層は主要なモデルだけ
- ストレージ部分は手抜き
- RedisとHashMapに対応したリポジトリだけで実装（オンメモリで）
- チームメンバーにDDD経験者は一名のみ
- メンバーのモチベーションはあった
ユビキタス言語と実装をプロトタイプで説明
- プロトタイプの共有
- プロトタイプはDDDありきだった
- 前提であるアーキテクチャの共有
- ドメインモデルの見本でユビキタス言語を共有
- 大枠のユビキタス言語が共有できたら、プロトタイプを捨てて、作り直した。
- ほぼ毎日の読書会（エリック・エヴァンスのドメイン駆動設計）（以下DDD本）もやった
ユビキタス言語の例
- このプロジェクトにおいては、ChatRoomではなくConversationと呼ぶ
スプリント内で使えるドメインモデルを実装
- 最も重要なモデルをストーリーから探す
- 会話とは何か？支える文脈を探す。共有する
- 例
- ユーザーとして会話に参加できる
- ユーザーとして会話に対してメッセージを送信できる
- ユーザーとして会話から離脱できる
- 正しいかそうでないかではなく、どちらのユビキタス言語が適切か
- 例：メッセージ送信のユビキタス言語はどちらか？
- ユーザー自身が他のユーザーにメッセージを渡す
- ユーザーはメッセージサービスにメッセージを渡す
- 議論
- ドメイン層のクラスのメソッド、プロパティがなぜそこにあるか
- 違う言葉を使う人がチーム内にいなくなる
- どっちが正しいかではなく、チーム内で合意できること、納得できることが大事
レイヤー化アーキテクチャに組み込む
- レイヤー
- UI
- Application
- Domain
- User
- Message
- Conversation
- etc
- Infrastructure
- Domainは他のレイヤに浸食されやすい
- UIに浸食された例
- UserのtoStringでユーザーの名前がspanタグに囲まれてかえってくる
- UserがSaveメソッドを持つような実装はありがちだが、対応するユビキタス言語があるかが重要
テーブル設計は必須
- データ駆動ではなく、まずモデルを決めてどうやってエンコーディングするかを検討した
JSON
- ドメインモデルをどうやってエンコーディングするか
SNSチームの事例
- 模造紙を用意し、付箋紙でモデルを書き、貼り付けていく
- メソッドやプロパティは書かない
- サブドメインを作成
- それを見せると、新しく入ったメンバーがシステムの概要を掴みやすい
DDDってぶっちゃけどうよ？アンケート
開発メンバーにアンケートを実施し、5人から回答をもらった。
DDDをやってみて効果あった？
- 効果がないと答えた人はいなかった
- 非エンジニアとコミュニケーションしやすくなった
- 新メンバーが参画してもコンテキストやモデル知識を共有しやすい
- レイヤー化アーキテクチャを採用したことで、ソフトウェア構造が明確になった
- 要件と成果物の関係性が明確になった
実践する苦労はあった？
- 全員がDDDを知っている必要がある
- シャーディングなどの技術的な問題とリポジトリーパターンの愛称が悪い
- DDD本が抽象的すぎて、実際の設計や実装レベルでどうするかが人によって異なる
- ドメイン／非ドメインコードの区別ができるようになるのに苦労にした
- 集約と性能問題のトレードオフが難しい
- エンティティが集約になっていく
- オブジェクトの一貫性を守る
- オブジェクトはひと塊としてI/Oするもの
- 一部の属性だけLasy Loadするのは難しい
エンティティのIDとDBMSのシーケンスとの相性の悪さ
- 識別子はシーケンスに依存するものではない。それが前提の設計はまずい
- ID生成器を実装するのがトレンド
読書会を実施した効果はあった？
- 「どちらともいえない」が１人、それ以外の回答は「効果があった」
- ユビキタス言語の重要性を理解できた
- 知識に対する共通認識の基盤が作れるという意味で効果あり
scala-dddbase（DDDを支援するフレームワーク）導入効果は？
- 「はい」３人、「どちらともいえない」２人
- Entity、Repositoryが定義されていて開発が楽だった
- DDDの考え方が自然と身についた
- 必要なインターフェースがあるので独自に増やすことがなかった
次もDDDを採用したいか？
- 「どちらともいえない」４人、「はい」１人
- 規模や期間にもよるが、少なくともある程度のエッセンスは使っていくと思う
- プロジェクトの規模によって有効な場合とそうでない場合があるため、プロジェクトによる
DDDの難しさは？
- チーム全員がDDDを理解する必要がある
- エンジニア間、非エンジニア間でのドメイン駆動設計に関する知識の共有
- 同じ言葉でも捉え方はさまざまであるため、わかったつもりになり、問題が発生するまで異なっている事に気付かない
- 言葉の解釈を共有するのが難しい
- シャーディングなどの技術的な問題にぶつかったときにDDDの思想を守りつつ、どのように解決するか、どの程度妥協するか
- コミュニケーションをとれるモデルを保ちながら、性能も追及していく
- 性能だけを追求して読めないコードを書いてしまうと、開発者が苦労する
参考文献
| エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) | ||||
|
関連エントリー
「JJUG ナイトセミナー 6.11 ドメイン駆動設計特集！ 」に行ってきた（その１「コードに語らせるために」by グロースエクスパートナーズ株式会社 和智 右桂さん） - プログラマーな日々
