読者です 読者をやめる 読者になる 読者になる

「DDD Alliance! ドメイン駆動設計をやってみた 6つの現場からの報告」に参加してきた #DDDAlliance

2015年11月10日に開催された「DDD Alliance! ドメイン駆動設計をやってみた 6つの現場からの報告」の抽選に当たったので参加してきました。

ddd-alliance.connpass.com

第一部 ビックローブでの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メソッド

  • あらゆる操作をsaveメソッドのみで対応
  • BaseRepository作ってみた → カオス感Up!
  • 業務イベント事にメソッド用意したほうがシンプル

他集約のRepositoryを操作

  • アプリケーション層のコードだけでは関連する集約が把握できない
  • やめよう

SQLに業務ロジックが混在

  • はがそう
  • 主キーのみで検索してドメイン層で絞った方が良い

まとめ

  • DDD本と実践を行ったり来たりして理解を深めよう
  • サービスが存在する限り変化しつづけ、成長しつづけ、価値を届け続けるソフトウェアを作ることが大事

第二部 受託開発の現場から

ドメイン駆動設計を実践するプログラマーの悩み

  • プログラミングの面で悩んでいること
  • 今は3層レイヤとドメインロジックで構築

気をつけていること

  • モデルの歪みに気づけるか
  • 人は作りやすい方向に流れてしまう...
  • モデルにロジックを集める方向に作りやすくする

辛いこと

UIからのデータバインディング辛い

  • publicなsetterがひつよう
  • 場合でデフォルトコンストラクタ必要
  • 型のミスマッチ
  • 階層を持った多肢選択UIや一覧表入力系UI

UIすぐに変わるし辛い

バリデーション辛い

  • 型のミスマッチ
  • 意味的なチェック
  • DBを必要とするチェック
  • 限定的な文脈でのみ行われるチェック

まとめ

  • データ境界面が主に辛い
  • Javaから何かに変換するのはあまり辛くない
  • 何かからJavaに変換するのが特に辛い

ドメイン駆動設計におけるシナリオテストの活用

シナリオテストの動機

  • ウォーターフォール的にすすめていた → 最後に大量のフィードバック → 辛い
  • アジャイル的 → 毎週打ち合わせ、成果物リリース → 画面をできるだけ早く揃えたいが、出戻りをできるだけ防ぎたい

BDDでシナリオをテストコードで表せれば顧客からのフィードバックを受けやすくなるのでは → Spock採用

効果

  • 開発にリズム感でた
  • ちゃんとした実装は後回し
  • 仕様の合意でたら実装にスピード感出る
  • 声に出して読み合わせして毎週フィードバック得られる

今後

  • よりよい可読性を目指す
  • 複数モジュールやコンテキストをまたいだテストを書けるようにする
  • どこまでテスト作るかの見極め
  • 画面を作るタイミングの見極め

第三部 内製の現場から

ECサイトのリプレイスをDDDでやってみた

背景

サービスをちいさく分割したい

某殿堂の圧縮陳列(ドンドンドン・ド○キー♪)

やってみた

ドメインモデリング

  • ドメインエキスパート不在...RDBからモデリングしてしまった
  • 結果として知識を噛み砕けていないモデルを作っただけだった

実装

  • レイヤー化アーキテクチャ
  • レイヤの役割やコンテキストを意識できた
  • DDDの実感ここだけ
  • ドメインモデルをきちんと落とし込めないと意味ないと増田さんからバッサリ

結果

  • いわゆるドメインモデル貧血症に陥る
  • 振る舞いを切り捨ててしまったのでDDDを導入した意味がなかったかも
  • チームでもっと言葉を使って探求すればよかった

その後

  • DDDの普及活動(読書会)によって仲間が最近増えてきた

最後に

  • たぶんDDDに正解はない
  • チームが言葉で話して納得できたらそれが正解
  • DDD本←→実装の反復作業がより理解する近道

ガチDDDを経てDDDって何?って現場に行ったあるプログラマーのお話

www.slideshare.net

DDDとの出会い、DDDと離れて、再び導入した話

DDDって?

転職してDDDが無い環境へ

  • ロジック分かれてない、ドメインが無い
  • リファクタリングでごまかしてたが拉致があかない → 勝手にDDD
  • 1つ何か対応するたびに20以上クラスが増える、毎日嫌がらせのようなPRを出し続ける
  • 気づいたらレビューしてくれるメンバーが似た感じのコードになっていた。

DDD導入には

  • エヴァンス本や勉強会で知識高めることも大事
  • 実際に手を動かすことの方が重要かも

最後に

ドメイン駆動設計のススメ

悪しき習慣

  • 基本データ型でプログラミングする→型を独自に定義しない
  • 動いたら設計を辞める → 本当に業務をあらわせているか?
  • コードを書く前にドキュメントを準備する
  • 分析/設計/実装を別の人間がやる
  • 分析/設計/実装を別の日にやる

身に付けるべき習慣

  • 独自の型をどんどん作ろう
  • 動いてるコードの設計改善に時間をかける -- まずコードを書いて動かす -- 動いてるコードに対して議論して設計改善する
  • ドキュメントは(必要なら)コードから生成する
  • 分析/設計/実装を同じ人間がやる(鉄則!!)
  • 毎日、分析し、設計し、実装する

学び方

書籍から学ぶ

コードから学ぶ

  • 動いてるコードを対象に設計改善を議論する
  • 動いてるコードを変更する
  • 設計の違いの効果を実感する

まとめ

  • DDDやったからといってすぐ見違えるわけではない
  • DDDをやりながら実感を増やし徐々にかわっていく

最後に

おなじみケント・ベックの言葉

どんな状況でも改善できる
どんなときでも「あなた」から改善を始められる
どんなときでも「今日」から改善を始められる

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 94人 クリック: 3,091回
  • この商品を含むブログ (312件) を見る

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

エクストリームプログラミング

エクストリームプログラミング