# DDD Radio #1

## 自己紹介

### かとじゅんさん

* Chatwork社
* DDDは2009年から
* サーバーサイドメイン

### すえなみさん

* 数社で開発のコンサル・技術顧問
* Rails・PHPが多い
* 最近はReactも触ってる

### ミノ駆動さん

* クラウドワークス社
* リファクタリング専門
* 半年前からWEB開発に

## 実際の事例

どうやって導入したか、失敗などの事例をスピーカーの方々がお話されました。

### かとじゅんさん

* 原著読みながら四苦八苦してた
* 金融系のシステムで実践したのが最初
* ペアプロ
* ユビキタス言語は作れたけど、実装上の表現はうまくいかなった
* いわゆるドメインモデル貧血症
* RDRA・ICONIX・イベントストーミングなどを試行
* 現場の方が既に知っていてある程度導入されていた
* 循環的複雑度をツールを使って確認
* 高くなるとテスト不能になる

### すえなみさん

* インバウンド向けツアー
* CtoC、Rails
* ガイド・旅行者からの要望が増えて複雑になってきた
* 一部Rails→Javaへ
* Rails側はプレゼンテーションに集中できるようになった
* 切り離したところは現状技術駆動寄り
* モデルを共有いかに共有するかが課題
* 複雑な箇所（コアドメイン）から切り離し
* リスクは高くないのか？
* ユースケース自体は多くない
* サブドメインを変化させず、コアドメインだけに集中した
* Javaを選択した理由
* 静的型付け言語がよい
* Javaを書ける
* Railsとチームは別
* 強い人一人
* クラス結合度を見ている
* Visual Studioで見れる
* パッケージ・クラス・メソッド単位で見れる
* 変更した時の影響範囲
* 依存の方向性が重要

### ミノ駆動さん

* ファットモデルが多い…
* 複数の概念が混在している
* お金が関係してないのに金額計算ロジックが入っている
* ドメインオブジェクトを抜き出していくと・・・
* 概念が明瞭になった
* 仕様の理解が進んだ
* if文が減った→コードが読みやすい
* リファクタリングの効果が高い箇所から実施
* [code climate](https://codeclimate.com/)を使って技術的負債を可視化
* ファイルの変更頻度も出してくれる

## Note

* リファクタリング対象にする基準が必要だと書かれていたけど標準化した？
* レガシーソフトウェア改善ガイドより
* 価値
* 難度
* リスク
* 変更頻度が高いところは対費用効果も高い

* * *

## After show

### ミノ駆動さん

* 権力者にManagerクラスを作りたがる人が多い印象
* 新人さんの育成
* switch書きそうになったらストラテジパターンを実装してみる
* 「ドメイン駆動設計」という言語を使わないようにする
* 未知の単語を聞くだけで警戒度が増す
* VO, ファーストクラスコレクション, ストラテジ, 仕様パターン
* ビッグリファクタリングはダメ
* 小さくリファクタリングしていくことが大事
* プロダクト全体のリファクタリング
* 結果的に頓挫した
* コードを良くするというモチベーションが重要だが、小さな達成の積み重ねの先にあるもの

### すえなみさん

* 知識がない説
* ビジネスの理解か実装の理解か
* ifをなにも考えずに実装せず、代替手段を考える
* ホワイトボードにユビキタス言語を付箋に書き出す
* 向き合っているビジネス対象を明確にできる
* 既存の実装と既存のFWと戦わない
* ARと戦ったら負ける
* DDDはさておき、実装パターンを試すことがオブジェクト指向設計的には正しい
* オブジェクト指向は前提になっている
* DIPが実現可能な言語でないとつらい
* コミュニティの力も大きい

### かとじゅんさん

* ルールを強いるのは設計なのか？
* インプット過多を避ける インプット:アウトプット=3:7
* 自分で学習していくしかない
* 部分的に実装パターンを導入できるのであれば可能では？
* リファクタリングは際限なくできる
* 1日で終わるものは共有しない
* 不要な合意で時間が取られる
* 1日以上かかる規模だと共有する
* PHP→Scala
* インクリメンタルなビッグリライト

### 松岡さん

* モデリングと実装はどちらか一方できれば良いというわけではない
* どちらを先に始めるかの違い