後半バッテリーが終了してメモれてないです…
ごめんなさい！
第1部 ビッグローブでの2年間の取り組み
1. DDDを組織で始めるための考え方
Cloud works 入社したら人事部長ｗ
今回はBIGLOBEの話
2，3年で10数チームできた
スクラムでやった
15年分の独自言語のシステムをコンテキストマップとか作ってみたけどカオス
独自言語→人が成長しない
業務ロジック書くのが人によってマチマチになる。あるある
スクラムを始めたときのように小さなチームを作って初めて見た。
守破離
研究だけだと日の目を見ない。あるある
実際の案件でやった→一回失敗した→もう一回やった！！！
楽しかったという思い出
のれん分けで広げていった
広げるときは一気にやっても難しい。
ノウハウは人に貯まる。暗黙知。
組織に導入するポイント
やったことないところに導入するためには
- 小さくやる
- 知ってる人に教えてもらう
- のれん分け
もっと重要なのは結果を出す！！！
強い意志が必要。
責任から逃げちゃダメだ
なぜDDD?
抽象的な話。
「クリストファー・アレグザンダーの思考の軌跡」から言葉を拝借
- デザインはニーズを認識すること
- デザインの究極的な目標は形だ
- コンテキストはほにゃらら
設計の同期は自分たちの外にあるべき
会社変わって普段デザインやってる人達の話し聞いてたら課題は何かをずっと話している
なぜを考えている。
何を作るかはあくまで手段。
DDD本も具体的なコードの話は出てこないことからそういうことなんだろう、と。
事業目的もどんどん変化していくんだからそれと一緒にグルグルリファクタリングしていく。
システム全体としての考え方
サービスとコードを繋ぐとサービスについて考えるようになる
変化へのしなやかな対応で変えることが当たり前になる
コンセプトは人。
現実的にはすぐに解決できない問題だらけ。
何するのも人がやってる。そこを考える。
道具（DDD）を変えることで人は成長する。
アジャイル、スクラムとの相性はいい。
組織として戦略的に取り組む必要がある。
施策を考える人と開発する人が一緒にやっていく塊は今やってるからこれからも維持していきたい。
総合的に組織を作る。
経営層と繋がっていく。
エンジニアの地位を上げていく！
2. 開発現場から学んだドメイン駆動設計中心のサービス開発
BIGLOBEでDDD導入して早2年
主要なところは大体DDDでやれてる
- 全開発者でDDDの価値を共有
- 現状の課題分析と課題解決に向けての行動
- 人材育成計画（現在30名くらい）
- どういう人に今後引っ張ってもらうかなど考える
- 新たな技術にチャレンジ
- 開発環境基盤の高度化もチャンとやる
- デプロイとかもしっかりやる
DDDの価値
コアドメインは何か？
開発メンバーも一緒に考えようぜ。
サービス継続←変更し続ける←人も変わっていく
5年10年を見据えたサービスを考えるのは難しい。
- コスト削減
- 変更コスト
- 俗人か低減
スクラム
アプリケーション層の設計に近い
方向付けレベルの設計に止める
サービスをシンプルにできるならシンプルにしましょう。
全ての実装を満足にできるわけではないので、コアドメインを重点的にやる。
WIPプルリクして効率的にレビューしてる。
でかくなるとわけのわからんものになるから注意。
違和感に敏感になる。
書き言葉と話し言葉がずれたら警告！
コアドメインはほったらかしにしたら絶対にアカン
チームビルディング
チームビルディング大事。
「チームが機能するとはどういうことか」
学習しながら実行する＝DDDで必須の考え方！
DDD採用してるのは長い目で見たコスト削減にもなるので、当てはまるところが多い。
全員で設計→ファシリテーションが大事。
会議中にPCいじってる人がいるのはNG。
みんなで考える。
意見を引き出す→ファシリテーターの仕事
ギャップをなくす
ノウハウを伝授するためには…
過程も含めて伝える
メンバー自身にモデリングさせる。
リーダーとかが書いたら意味ない。
モデリング
肥大化を防ぐために外側に出したりする。
Immutable Data Model
ひたすらInsert
NULLの項目が激減する！
失敗談
リーダークラスで集まって出してもらったら20コくらい出てきたｗ
- ドメインモデルが古くてメンテされてない
- Policy乱立問題
- Repositoryのsaveメソッド
第2部 受託開発の現場から
ドメイン駆動設計を実践するプログラマーの悩み
プログラミングの面で悩んでること、解決策が見いだせてないものの話
ドメイン駆動設計におけるシナリオテストの活用
BDDやってみたらいい感じだったという話