座談会って？
飲み会を公開版にしたもの

セミナー形式の一方的な勉強会ではなく、参加者全員で話し合う座談会形式の勉強会

パネラー紹介

増田さん
- ドメイン駆動設計＝オブジェクト指向+XP+国語力
- 最近フォーカスしてること
  - 原点回帰っぽくなってきてる
  - 変更容易性にこだわってる
  - モジュール性→オブジェクト指向だね
- コード書きつつ実戦しつつ
末並さん
- 糖質警察
- 女性向けのキュレーションサイト
- DDDは実戦してない、できてない
- Rails、Active Recordの壁があってそのままDDDてのはできてない
- チームビルディングとかに使ってる
- メディアｘDDD、スタートアップｘDDD
  - 誰も詳しい人がいないときにどうしていくのかを考えてる
原田さん
- DDDでたときに、ほうってなっていいもんだということでやってる
- From 2004
- DDDやっても開発チームが100人いるとけっきょく大変
- 開発チーム、プロセスをどうするってことがメインになってきてる
- ソフトウェアはかわいくないとダメ
奥田さん
- バックエンドを高負荷に耐えられるようにScala + DDDで再構築
- Reactive Messaging Patterns読書会
- DDDは2週目からが本番
- ユースケース駆動開発実践ガイド
  - DDDの中にプロセスがしっかり定義されてるわけじゃないので、そこら辺をカバーする意味でいい感じ
- メタ思考トレーニング
- かんばん仕事術→近々感動する予定
かとじゅんさん
- Scala化どうなった？
- なかなか壁が厚い
- DDD担当
- Akkaでやるとこれまでのメソッドベースのプログラミングスタイルがガラッと変わる
- これでやってるとどうしても技術的な言葉が出てきてしまう
- TwitterみたいなところはDDD合わないかも
- 実装する上で集約が超大事
  - 契約による設計とかに行き着く

全般

DDDに向いてる要件は？費用対効果は？

DDD実戦して作ったものが潰れたときのことを考えるとどうなんだろう？

原）
要件は気にしてない。
開発に関わる人数を少なくできるかどうかを考える。
9人程度でできるものはDDDでやっちゃう。
DDDは発見の旅。
全体で使ってメリットがあるかどうかと言うと、ない。

Q)
システム全体が大きい場合、コンテキストを分けてチームを分けて7，8人だったらどう？

原）
暗黙知を共有しているからユビキタス言語が通用する。
意思決定のやり方が共有されてるかがキモ

増）
ソフトウェアの変更があるならDDDをやる。
変更のないことが分かっているものであればおそらくコストは回収できない
エンジニア個人としてはそういう案件でもチャレンジしてほしい。

奥）
システムは1回作って終わりではない。
継続的に成長させたいものがあるのならDDDはいい。

か）
ソーシャルゲーム会社でDDDの話したことがある
荒ぶる四天王
プロジェクトの性質上、納期を守ることが一番の価値というのがよくある。
モデルについて考えてる暇がない。
ドメインビジョン声明文はすごい大事。
自販機ドメインのワークショップする
方針として、利益を最大化する自販機というのを目標にする。
これを考えると何をしていいか悪いかを考える。
4時間くらい話してる時がある。
注目することが違うと全然違う。
経営戦略と合致していないと意味がない。

末）
その概念、機能が会社にとってどれだけ大事にされてるかの観点で見て決めてる。
数ヶ月後にユビキタス言語になってるかもしれないとかを考える。

Q)
途中からDDDやってみようってなった時にやれるのか？

原）
3ヶ月はやっつけで作った方がいい
3ヶ月後に生き残ってないものは変更しないし価値がない
3ヶ月後からリファクタリングすればいい。

奥）
Railsでスピーディにやってたのはよかった。
後から思うと静的型付け言語がいいなと思うことがあるので、最初からやっててもよかったかな、と思ってる。

増）
2種類のプロジェクトしかやってない。
新規のプロジェクトか、火を噴いたプロジェクトか。
変えるためのエネルギーは大変。

Q)
やっつけで作ったものは作り直すのか？

原）
最低限データをどこに入れるかは考えとく。
後でリファクタリングするときにデータのルーティング
Railsはデータベースをmodelに書いてる時点でダメ

Q)
Active Recordはドメインモデルといっていいのか

末）
ダメですねｗ
Railsはコミュニティの強さ。
DDDとの相性は悪い。
システムの中でユビキタス言語を見つけることくらい

か）
使えるモノを部分的に採用してる感じ

会場）
規模が大きい方がDDD使ったほうがメリットがでるんじゃないか
Railsの場合は大体小さいから合わないんじゃないか。
大きいほどユビキタス言語大事になるんじゃないか

原）
逆の意見。
小さいところのシステム境界を明らかにする。
小さい部分を小さく作れるようになると大きいのもいけるようになる。
小さいところからジワジワ広げる。

会場）
システムの規模とデータ量はある程度の相関はある
原田さんが言ってるのは人数。

原）
使えないのをやってもしょうがないので、みんな鍛えればいいよね、って話
一桁人数ならみんながレビューできるよね。

会場）
共通認識が持てる人数でやることが大事。

原）
ソフトウェアの成熟度合いグループ
DDDやってるとコードはコンパクトになる。

増）
規模は関係ない。
でかい規模の方が効果はでかくなる。
けど、コミュニケーションの問題とかあるとは思う。
14章か17章で誰が設計するのかてのが書いてあってそこら辺がキーになりそう。

原）
アーキテクトは実装する。
実装できないのはアーキテクトじゃない。

DDDを採用して後悔したこと、失敗したこと

増）
仕事としてソフトウェア作ることに関しては反省点はあるけど、結果は出せている。
あのときがんばっとけばよかったな、と言うことはある。
納期とか要望とかの優先度の兼ね合いでできなかったところがいけてないってことはある。
失敗したって感覚はない。

原）
現場ですげーうまくいったって言われることはないｗ
やり玉に挙げられることがある
練習が足りてない。
経験者がいないのに練習なしでできるわけない。
課外授業、週末プロジェクトやってみるとかした方がいい。

会場）
Python使ってやってみた。
色々実装して変更点が多くてチームが疲弊した
Readの部分はDDDじゃなくてもよかったと後悔

か）
Repositoryが複雑化していく。
findByXxxが増える。
疲れたことあるのでCQRSやってる。
タスクベースに。
Writeモデルの変化に対応してReadモデルを変更してる。
Write側はシンプルになるけど、Readが複雑になる。

開発プロセス

全体に関わるドメインの管理について

原）
ユーザーはエンティティじゃない。
アイデンティティとロールの話。
Open ID Connectがそこら辺まじめになってる。
ユーザーはユビキタス言語な分けがない。
ロールがモデルに書かれる。
少なくとも共通カーネルのエンティティではない。

会場）
アカウント管理のドメインにおいては、副作用のあるモノとして扱う
それ以外の所は値オブジェクトとして扱うといい感じだった

質問者）
ユーザーはほぼどのコンテキストでも使われる。
共有カーネルにするべきなのか、そこら辺がはっきりしない。

か）
チャットワークでも、メッセージングコンテキスト、課金、管理それぞれのコンテキストでユーザーが違ってくる。
一般のアカウントっておそらく共通言語じゃない。
コンテキストによって違う。
コンテキストを踏まえないで語っても仕方がない。

奥）
コードの重複とかはあとで考えること。
データの振る舞いとかで分けられないか。DCI
シェアしない方が変更のしやすさとかあるんじゃないのかな。

原）
コンテキストはMECEじゃない。

増）
コンテキストによって違うのは賛成。
共有カーネルについて
そこに集約させて意味が出てくるならやった方がいい。
単純に共通だから共有カーネルでやるのは違う。
認証の仕組みだけを共通にするとか。
凝集したメカニズム。

末）
コンテキスト依存の振る舞いはコンテキストに押し込むのが好き。
Railsでやろうとするとパフォーマンスがでなくなる。
コンテキストから外れたときに外すとまともになる。
ユーザーをIdentifyすることについて
アドテクではいろんな方法がある。
IDをマッピングして同一人物であることを認識する。
一つのIDで特定できない感じになってきてる。
マルチデバイスの時代なので。

都）
Open ID Connect
ベースとなるアイデンティティが複数ある場合
一つの整理方法として、システムが認識した一つのアイデンティティとしてエンティティにできるのではないか。
関連のエンティティで書き込み能力を付与する別のエンティティができるんじゃないか。

原）
今のシステムってログイン前からトラッキングしたいときがある。
ユーザーで一意になっていない状況がある。

戦略面、戦術面

イベントソーシングの話

ドメインイベントを中心とした結果整合性でシステムを組んだ場合、
処理失敗時の通知など複雑になるけど、どのように対応しているか

か）
集約は整合性を維持する単位
CQRSでイベントソーシングやってる。
アクターにコマンド投げる
集約をアクターに投げてる。
Akka Persistence
コマンドを受けるとイベントが発火される。
イベントがジャーナルとして保存される。
イベントデータポンプ
イベント列ごとに書き込んでいかないといけない。
Writeで受ける不変条件は絶対に破られてはいけない。

原）
生産管理でいうと
出荷っていうトランザクションじゃない。
出荷依頼ていうトランザクション。
やれじゃなくて、お願いする感じ。

か）
非同期の境界がたぶん違う
I/Oの集約はシーケンシャルに。
書き込みを受けつけましたとかのレスポンスを返す。
ポーリングで状態を返したり、完了したら能動的に返したり。

奥）
失敗通知が難しいことについて
質問者の意図が知りたかった

会場）
在庫の場合は
アトミックにやった場合は良いけど、結果整合性でやった場合どうするのがいいのか

か）
業務的にやってはいけないものはある

原）
アトミックな在庫システム作るやつは素人
フローで考える必要がある。
アトミックなロックが必要な場合はどっか間違ってる。

か）
チャットワーク
部屋と管理者、参加者
3つを集約すると結果整合になる。
誰もいない部屋が一瞬できてしまう。
バランスが難しい。

増）
要求と選択している技術のギャップがでかいから悩んでると思うので、
どっちかに振り切った方がいい。
在庫とか部屋とか一瞬変な感じになってもいいじゃん。
ダメならそっちに倒すしかない。

原）
会社の勘定はアトミックじゃなくて結果整合性。

会場）
設計上どこに落とすかじゃなくて、UX設計などのプロセスじゃないか。
先に言えればいいけど、どうするかが難しい。