「DDD Alliance! ドメイン駆動設計をやってみた ６つの現場からの報告」に参加してきた #DDDAlliance
2015年11月10日に開催された「DDD Alliance! ドメイン駆動設計をやってみた ６つの現場からの報告」の抽選に当たったので参加してきました。
第一部 ビックローブでの2年間の取り組み
DDDを組織で始めるための考え方
1. DDDはじめの一歩
当時のビッグローブでは内製をしておらず外注メイン、プログラマがいないスクラムを始めた → メンバーが増え、2、3年で十数チームできた
課題：アーキテクチャ
- 15年稼働しているシステム
- 独自言語で書かれている(!)
- 複数の会社に外注してた
結果: カオス!
コンテキストマップ作ってみたけどわけわかんない
スクラムでも成果でそうになかった 独自言語で人が成長しない
課題: 業務ロジックの設計
- MVCでは足りない
- ある日：DDDがいいのではというメンバー
- DDDおじさん(増田さん)の記事→呼んでみよう!
増田さんの言うとおりに守破離の守
作っては壊しを3人で半年
取り組んだこと
できそうな気がする → 案件探し
案件の条件
- 「新規サービス」
- 小さい
- 他に影響しない
- 納期調整可能
独自言語を書き直し機能追加も→うまくいった!
暖簾分け→育ったメンバーを別チームに配分して拡大する
時間かかるが暖簾分けおすすめ
2.組織に導入するポイント
DDDのような組織がやったことがないことをやるには
- 小さくやる 5人くらい
- 知っている人に教えを請う
- 暖簾分け
重要：結果を出す
3. なぜDDDか
クリストファー・アレグザンダーの思考の軌跡より
設計の仮設：設計（デザイン）の動機は自分たち（プログラミング）の外にあるべき
DDDの価値とは
組織全体として考え方を統一する
- サービスとコードをドメインでつなぐ → サービスを考えるようになる
- 変化へのしなやかな対応 → 変えることが当たり前になる
やるのは「人」
設計する人、サービスを使う人、プログラミングする人
開発メンバーの成長 道具を変えることで人は成長する アジャイル スクラムとの相性は良い
まとめ
サービスを考える人(経営者)と作る人との理解がつながる。これをしないとサービスが良くならない
キーワードは「統合」
開発現場から学んだドメイン駆動設計中心のサービス開発
www.slideshare.net
- 現BIGLOBE社員
- リードエンジニア（技術リーダー）
導入
- 5チーム/30人気簿でDDD
- 目標は100名くらいでやりたい
大事にしてること
- DDDの価値を共有
- 課題分析と解決に向けての行動
- 人材育成計画
- 新たな技術(CQRSとか)
- 開発環境基盤の高度化
DDDを採用する価値
- エンジニアもサービスの価値を考えないといけない
- サービスの継続が大事(人増える、変化多い、価値が変わる) 5~10年
独自言語はサービスの維持が精一杯
DDDの価値→サービス終了までのトータルコストの削減
変更コスト、属人性を下げる→業務をコードで表す
チーム環境の考え方
立ち上げ時の心構え
- 開発初期はわからないことだらけ
- 方向付けのレベルの設計に留める
- コアドメインを議論することはサービスを理解する第一歩
- サービスの複雑性と向き合う(大事)
スプリント
- ドメインモデルとコードを結びつける
- モデルの持つ糸をコードに引き継ぎコードを通してモデルにフィードバックする
- 設計者と実装者を分離しない
スプリント時の心構え
- コアドメインの設計・実装は重点的に
- 時間の都合上、すべての設計を完璧にはできない。
- プルリクエストのWIPを活用して効率的にレビューする（バックログ取ってから半日でPRがでる）
- スプリントごとに重要な概念を追加、ふような概念を削除
- 普段の会話のぎこちなさに敏感になった
- 書き言葉と話し言葉がずれたら警告
- 初期のドメインモデルや実装では重要で
- 見つけた問題を放置すると困る（特にコアドメイン）
- ドメインモデルを改善するプロセスが大事
チームビルディング
- 人的要因がパフォーマンスに影響
- 相乗効果(1 + 1を3以上にする)
- 知識（要求）は変化する。知識の共有が大事
DDDにおけるチームビルディング
「チームが機能するとはどういうことか」
- 学習するための組織づくり
- 学習しながら実行する → DDDで必須
リーダーは方向性を定める
- 絶えず少しずつ変化することが日常的
- 双方向のフィードバック
- 社員の判断は不可欠
- 目標：長期的な価値を生み出すこと
チームビルディングの内容
1. 全員で設計する
- メンバーが考える場所を作る
- メンバーの意見を引き出す
- メンバー間のギャップをなくす
メンバー全員が同じ地図を（ドメインモデル）を理解するため
設計の目的と効果をメンバー全員が理解して実装するため
熟練者のノウハウを経験が浅いメンバーに伝授する
2. モデリング済みの部分も積極的に改めてモデリングする
- メンバー間で確認
- 機能強化時、プランニング時、コードレビュー時、いつでもやる
- 経験が浅いメンバーはモデリングする機会を増やすことが成長につながる
- 新規加入メンバーはドメインを理解するチャンス
- 大事：モデリングはメンバー自身に実施させる（考えをアウトプットさせる場）
結果:
- チームの設計力が向上
- 変更コスト、属人性が下がる
- DDDを採用する価値を実感
まとめ
- DDDはチームビルディング大事
- 全員で設計に参加
- 既存部分も設計しなおそう
開発
- コアドメインになりそう、変更がありそうな所は積極的に分離
- 業務を中心に添えると業務ごとにデータが増えるのが自然
- Eventテーブル: 業務(申し込み、契約、解約など)ごとに用意。Insert中心。イベントログとしての役割。
- Stateテーブル: 業務によってUpdate。Eventテーブルの補助としての役割。データアクセス層の関心事で利用。
- imuttableデータモデルを使用するとNULLが減って良かった
- アプリケーションのみでなくDBで業務ロジックを表せられた
失敗談
ドメインモデルが古い
Policyクラスの乱立
- 業務チェックのために
- エンティティから業務ロジックが減っていく貧血症
- Policyパッケージを作った時点で負け
RepositoryのSaveメソッド
他集約のRepositoryを操作
- アプリケーション層のコードだけでは関連する集約が把握できない
- やめよう
SQLに業務ロジックが混在
- はがそう
- 主キーのみで検索してドメイン層で絞った方が良い
まとめ
- DDD本と実践を行ったり来たりして理解を深めよう
- サービスが存在する限り変化しつづけ、成長しつづけ、価値を届け続けるソフトウェアを作ることが大事
第二部 受託開発の現場から
ドメイン駆動設計を実践するプログラマーの悩み
- プログラミングの面で悩んでいること
- 今は3層レイヤとドメインロジックで構築
気をつけていること
- モデルの歪みに気づけるか
- 人は作りやすい方向に流れてしまう...
- モデルにロジックを集める方向に作りやすくする
辛いこと
UIからのデータバインディング辛い
- publicなsetterがひつよう
- 場合でデフォルトコンストラクタ必要
- 型のミスマッチ
- 階層を持った多肢選択UIや一覧表入力系UI
UIすぐに変わるし辛い
バリデーション辛い
- 型のミスマッチ
- 意味的なチェック
- DBを必要とするチェック
- 限定的な文脈でのみ行われるチェック
まとめ
ドメイン駆動設計におけるシナリオテストの活用
シナリオテストの動機
BDDでシナリオをテストコードで表せれば顧客からのフィードバックを受けやすくなるのでは → Spock採用
効果
- 開発にリズム感でた
- ちゃんとした実装は後回し
- 仕様の合意でたら実装にスピード感出る
- 声に出して読み合わせして毎週フィードバック得られる
今後
- よりよい可読性を目指す
- 複数モジュールやコンテキストをまたいだテストを書けるようにする
- どこまでテスト作るかの見極め
- 画面を作るタイミングの見極め
第三部 内製の現場から
ECサイトのリプレイスをDDDでやってみた
背景
サービスをちいさく分割したい
某殿堂の圧縮陳列(ドンドンドン・ド○キー♪)
やってみた
実装
結果
- いわゆるドメインモデル貧血症に陥る
- 振る舞いを切り捨ててしまったのでDDDを導入した意味がなかったかも
- チームでもっと言葉を使って探求すればよかった
その後
- DDDの普及活動（読書会）によって仲間が最近増えてきた
最後に
- たぶんDDDに正解はない
- チームが言葉で話して納得できたらそれが正解
- DDD本←→実装の反復作業がより理解する近道
ガチDDDを経てDDDって何？って現場に行ったあるプログラマーのお話
www.slideshare.net
DDDとの出会い、DDDと離れて、再び導入した話
DDDって?
転職してDDDが無い環境へ
- ロジック分かれてない、ドメインが無い
- リファクタリングでごまかしてたが拉致があかない → 勝手にDDD
- 1つ何か対応するたびに20以上クラスが増える、毎日嫌がらせのようなPRを出し続ける
- 気づいたらレビューしてくれるメンバーが似た感じのコードになっていた。
DDD導入には
- エヴァンス本や勉強会で知識高めることも大事
- 実際に手を動かすことの方が重要かも
最後に
ドメイン駆動設計のススメ
悪しき習慣
- 基本データ型でプログラミングする→型を独自に定義しない
- 動いたら設計を辞める → 本当に業務をあらわせているか?
- コードを書く前にドキュメントを準備する
- 分析/設計/実装を別の人間がやる
- 分析/設計/実装を別の日にやる
身に付けるべき習慣
- 独自の型をどんどん作ろう
- 動いてるコードの設計改善に時間をかける -- まずコードを書いて動かす -- 動いてるコードに対して議論して設計改善する
- ドキュメントは(必要なら)コードから生成する
- 分析/設計/実装を同じ人間がやる(鉄則!!)
- 毎日、分析し、設計し、実装する
学び方
書籍から学ぶ
- リファクタリング本は何度も読んだ(一番現場で生きた)
- オブジェクト指向設計の原則
- エクストリーム・プログラミング
コードから学ぶ
- 動いてるコードを対象に設計改善を議論する
- 動いてるコードを変更する
- 設計の違いの効果を実感する
まとめ
- DDDやったからといってすぐ見違えるわけではない
- DDDをやりながら実感を増やし徐々にかわっていく
最後に
おなじみケント・ベックの言葉
どんな状況でも改善できる どんなときでも「あなた」から改善を始められる どんなときでも「今日」から改善を始められる
リファクタリング―プログラムの体質改善テクニック (Object Technology Series)
- 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2000/05
- メディア: 単行本
- 購入: 94人 クリック: 3,091回
- この商品を含むブログ (312件) を見る
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)
- 作者: バートランド・メイヤー,酒匂寛
- 出版社/メーカー: 翔泳社
- 発売日: 2007/01/10
- メディア: 単行本（ソフトカバー）
- 購入: 11人 クリック: 307回
- この商品を含むブログ (131件) を見る
- 作者: ケントベック,シンシアアンドレス,Kent Beck,Cynthia Andres,角征典
- 出版社/メーカー: オーム社
- 発売日: 2015/06/26
- メディア: 単行本
- この商品を含むブログ (4件) を見る
