Tweet
http://septeni-scala.connpass.com/event/13129/
先に感想
- 最近良く来るベルサール新宿グラント（JAWSDAYS, JJUG CCC）
- かとじゅんさんのほう
- スライドじゃなくコードベースでの説明
- 実践DDD本を読み始めたばかり（1章途中）くらいだけどなんとなく言ってる・書いてあることが分かる感じがあった
- コードはDDDの勉強にすごくなりそう
←今読んでる実践DDD本
- 原田さんのほう
- cacooとコードレビューをその場でデモしてくれたのはすごく良かった
- スプリント内でみんなが目標（タスク消化、プルリク消化）に向かっていけてる（いけてそうな）いい会社なのかな？と思った
- 疑問
- 今知人と遊びでDDDで何かつくろうとしているけど、ドメインエキスパートに当たる人がいないような場合はどうするんだろうと思った（そんなのはそもそもありえない？）
- 一緒に聞きにいった知人も言っていたが、ちょっとしたものにDDDをやるのは初期コストが大きすぎ（めんどいｗ）と言っていて、まあ確かにと思った。原田さんも言っていた気がするが、中長期的な保守があるかどうかはひとつの導入のポイントかなぁと思った。
アジェンダ
- 【加藤潤一】 Play2 with DDD 〜何からはじめて何に気をつけるべきか〜
- 【原田侑亮】 Scala × DDD × 弊社実践例
20:00~
執行役員さん挨拶 杉谷さん
- なんの会社か
- セプテーニグループ
- ネット広告 第二位（一位はCA）
- 一部署・一会社
- いっぱいある
- セプテーニグループ
- プロダクト
- 「GANMA!」 PlayScala、AngularJS＋TypeScript、Swift、UnitTest、Android Scala、スクラム
- 「PYXIS」 Play Scala、AngularJS＋TypeScript、DDD、UnitTest、スクラム
- ネット広告運用支援システム
- 「MANT」LAMP、レガシーコード改善ガイド
- 前回
- 新卒でScala、なんでScalaを使うのか
【加藤潤一】 Play2 with DDD 〜何からはじめて何に気をつけるべきか〜
- ユビキタス言語から考える
- ☓ 要件定義さえあれば、業務の知識が必要なくてもソフト作れる → ◯ 業務の言葉をソフトウェアにも持ち込む
- モデル → モデルの実装 → シナリオ → 最初に戻る
- 「ペットショップ」のモデリング
- Customer, Item, Category の関係性
- 新しいシナリオを追加する「買い物カゴ」
- カートは都度作られる？プールされているものを使いまわす？
- 「注文」という抽象的な概念を追加
https://github.com/j5ik2o/spetstore
- ドメイン層 はほかから中立であるべき
- ビジネスの世界までつながっているところなので、エンジニアの思いつきとかで勝手に改変はできない（しちゃだめ）
- WEBやUIなどからは隔離されている必要あり
- Viewのモデルとかもこの中にはいれない
- アプリケーション層
- ControllerにわたってくるJSONをモデルに変換（ただしこれはドメインモデルではない。WEB？モデル）。
- WEBモデルをドメインモデルに変換する
リポジトリ
- ？モデルを出し入れする
- ドメインモデルの永続化を担当（MySQLに入れたりとか）
- （コード解説）
- ☆ししおう
- リポジトリの実装は、JDBC版、メモリ版、KVS版とかできる
- store() とかでもthis を返す（副作用を意識しない、テストをしやすくするように）
- ドメインモデルの中では永続化はしない。ビジネスの世界なので。←のような永続化に対応するのはリポジトリの役目
1ドメインモデル複数テーブル
lazy でやったほうが効率が良いとしても、概念単位でIOすべき（トレードオフではある）
フルスタックフレームワーク内のORMを使うべきではない
- ドメインモデルはWEB用途だけではない（他にもバッチとかで使う可能性がある）
インフラ層
- ビジネスからドメインモデルを考えたところから、テーブルを設計する
- どこまでが１つか「集約」
- 今までは集約を意識せずに、バラバラに散らばった部品をプログラマがうまく組み合わせていた
- 1つの集約に対して、1つのリポジトリ
ドメイン層でDIしない？
- 集約単位でIOする
- 例：Cart（集約）内に、Customer（これも集約）が属する形にしない
class Cart(
...,
customerId: CustomerId, // OK
//customer: Customer, // NG
items: List[Item],
...,
){
...
}
- 質問
- リポジトリをどこに置くべきか？ドメイン層においている理由は？
- リポジトリがドメインを受け取るので、リポジトリをインフラ層に置いちゃうとインフラ層がドメインを知っている状態になってしまうので、インフラ層に置いちゃダメ。
- 「下が上を知らない」が個人的にはいいと思う（実装コスト上がる気がする）
- エンティティは☆バージョンを持つ必要あり？
- 要件次第、楽観ロックとか。
- リポジトリをどこに置くべきか？ドメイン層においている理由は？
【原田侑亮】 Scala × DDD × 弊社実践例
- 自己紹介
- C, C#, VBA, Scala
- Scala DDD を勉強中
- サーバ構築、DJ趣味
- 「顧客が本当にもとめていたもの」の絵
- DDDだと解消できる部分（ユビキタス言語）
- なぜDDD
- 広告は複雑で、長期の保守が必要そう
- エンジニアとディレクタの会話に溝
- 流行り始めていた
- 先生がいた（かとじゅんさん）
- なぜScala
- 会社戦略としてScala
- DDDのコンテキストマップをそのままコードに落とせる
- コードが少ない
- 実践のプロセス
- ユビキタス言語 → コンテキストマップ → ドメイン図
- ユビキタス言語
- 実はこれが面倒、でも重要（人が多いとより大変）
- ストーリー → Entity,VO,振る舞い
- POと相談
- ☆コンテキストマップ
- アプリケーションの世界地図
- ドメイン図
- コンテキストマップをクラス図っぽく起こす
- 実際やってみる！
- イベント管理アプリ
- Cacooで起こす
- 名詞を記入
- ユーザ、イベント管理者、イベント、イベント詳細、日付候補、○☓△、イベント参加者、回答
- 振る舞いを記入
- イベント追加、招待する、回答する、回答を集計する
- 名詞を記入
- DDDフレームワーク（ライブラリ） sisioh
- サンプルコード
プロダクトオーナーによるコード（trait）レビュー
- 実際にレビューしてもらう
- ユビキタス言語、コンテキストマップのチェック
- 名前、日本語⇔英語、メンバの確認
- 実際にレビューしてもらう
あるある失敗談
- 技術に引っ張られる
- 技術で業務を捻じ曲げない！
- 逆流現象
- インフラ層がドメイン層を知っている
- ドメイン層がアプリ層を知っている
- プロジェクト分割とか
- エリックが言ってることがわからない
- 技術に引っ張られる
まとめ
- ユビキタス言語、コンテキストマップ、ドメインを考えるときは技術を忘れる
- sisioh便利
- EntityとRepository周り
- プロジェクト分割で逆流を抑える
質問
- ？コンテキストを分ける判断は？
- サブドメインで分割はする。
- 「業務が違うから」分けるという観点。いろんな考え方ある
- ？コードレビューについて、やるようになった経緯は？
- かとじゅんさんから「traitでみてもらうといいよ」
- ？時間設けたりしている？
- プルリクでいつでもやってもらう
- ？プルリク重なって大丈夫？
- 24時間以内ルール
- ？２４時間以内の承認できなかった場合は？
- 口頭で説明したり
- 完了条件：プルリク承認していないと、ストーリーが完了していない。レビューが終わっていないとそのスプリントが終ったことにならない。
- ？コンテキストを分ける判断は？
