「DDD Alliance! ドメイン駆動設計をやってみた　６つの現場からの報告」の発表資料です http://ddd-alliance.connpass.com/event/21932/ ドメイン駆動設計を用いた受託開発においてシステムの仕様（期待する振る舞い）を顧客と合意する手段として（BDDをベースにした）シナリオテストを試行してみました。

1. ドメイン駆動設計における
シナリオテストの活用
DDD Alliance!
ドメイン駆動設計をやってみた ６つの現場からの報告
2015/11/10 井上 岳大

2. 自己紹介
•井上 岳大（いのうえ たけひろ）
•∼２０１３／３
•仙台のSIerでシステムエンジニア（受託開発）
•２０１４／４∼
•フリーランスプログラマー（主に受託開発）
•DDD Alliance 設立メンバー
•DDD勉強会in仙台（20回）/ TDD勉強会in仙台（24回）主催
•TDDBC仙台の運営 →11/14（土）TDDBC仙台５
•Twitter : @i_takehiro

3. 本日言いたいこと
ドメイン駆動設計を用いた受託開発
において
システムの仕様（期待する振る舞い）
を
顧客と合意する手段
として
（BDDをベースにした）シナリオテスト
を使ってみたらとても良い感じ

4. BDD/シナリオテストとは
【BDD】
・Behavior Driven Development
・振る舞い駆動開発
・システムに期待する振る舞いをスペック（仕様）として記述する
【シナリオテスト】
・シナリオ（１つまたは複数のユースケース）を
スペックとして記述する
・プレゼンテーション層から見た振る舞いをシミュレート
・アプリケーションサービスを介して、ドメインモデルの
参照や更新を行う

5. シナリオテスト導入の動機（１）
・仙台を拠点にリモートワークでの受託開発
→顧客は東京
→チームメンバーは全国各地（東京、大阪、青森 等）
【これまでの開発の進め方】
・コンテキスト図／ユースケース図／サイトマップの作成
・ドメインモデルの作成
→この段階で、一旦顧客と仕様の合意
・サービス層の実装（ドメイン層／インフラ層を含む）
→ある程度のフィードバック
・プレゼンテーション層（画面）の実装
→このタイミングで大量のフィードバック

6. シナリオテスト導入の動機（２）
【今回の開発の流れ】
・顧客の社内システム部担当者と毎週打ち合わせ
→毎週成果物をリリース
→打ち合わせで動くものでプレゼンを行う
・ビジネス的なプロダクトの優先度や仕様が常に変わっていく
（例）営業サイドからのフィードバック
→大規模顧客が欲しいと言ったら優先度急上昇
→パッケージを前提に開発を開始するが
必要ならば個社対応を行う
・プロダクトを売るためにはできるだけ早く具体的なもの（画面）を
開発する必要がある
→画面をできるだけ早く えたいが、出戻りをできるだけ防ぎたい

7. シナリオテストの導入
・TDD（Test Driven Development）大好き
→自分自身に対して頻繁なフィードバックが得られる
・シナリオ（ユースケース）をテストコードで分かりやすく
記述したら、顧客からの頻繁なフィードバックが得られて
仕様合意が進み、その後の出戻りを減らせるのではないか
→BDDをベースにしたシナリオテストを試作
→Java + Spring Boot での開発なので
BDDフレームワークとして
Spock Framework を採用
（今までもTDDフレームワークとして利用）

8. 開発の全体像
シナリオテスト
（ＢＤＤ）
ユニットテスト
（ＴＤＤ）
ドメインモデル
ユビキタス言語
サービス層 ドメイン層
インフラ
ストラクチャ
層
プレゼン
テーション層
ユースケース図
コンテキスト図 サイトマップ
フィードバック

9. 実際のシナリオテスト例
def "店長が自店舗の募集に対する応募を採用した後に募集を終了する"() {
when: "店長が採用したい応募の詳細を取得する"
def 未採用応募詳細 = 応募サービス.getDetail(応募ID_採用する)
then: "応募者が未採用である"
未採用応募詳細.memberId == 応募者ID_採用する
未採用応募詳細.signed == false
when: "店長が応募を採用する"
採用サービス.sign(応募ID_採用する)
then: "システムが応募者に採用通知を行う"
1 * 採用通知サービス.notify(_) >> { notice ->
採用通知内容 = notice[0]
}
採用通知内容.memberId == 応募者ID_採用する
and: "応募が採用されている"
def 採用済応募詳細 = 応募サービス.getDetail(応募ID_採用する)
採用済応募詳細.signed
def 未採用応募一覧 = 応募サービス.listNotSigned()
未採用応募一覧.contains(応募ID_採用する) == false
未採用応募一覧.contains(応募ID_採用しない)
and: "採用済済応募一覧に採用した応募が含まれる"
def 採用済済応募一覧 = 応募サービス.listSigned()
採用済済応募一覧.contains(応募ID_採用する)
採用済済応募一覧.contains(応募ID_採用しない) == false
when: "店長が募集を終了する"
募集登録サービス.close(募集ID)
then: "システムが未採用な応募者に募集終了通知を行う"
1 * 募集終了通知サービス.notify(_) >> { notice ->
募集終了通知内容 = notice[0]
}
募集終了通知内容.memberId == 応募者ID_採用しない
and: "店長が終了済募集一覧から終了した募集を取得できる"
def 終了済み募集一覧 = 募集サービス.listClosed()
終了済み募集一覧.contains(募集ID)
}

10. シナリオテストを活用してみて
【開発時】
・開発にリズム感が出る（BDD/TDD)
・開発に濃淡をつけやすい→ちゃんとした実装は後回し
(ダミー実装、集約の項目は最低限 など)
・一旦仕様の合意ができれば、実装にスピード感が出る
【打ち合わせ】
・実際にシナリオテストを見ながら声に出して読み合わせ
→毎週フィードバックが得られる
（ちょっとした言葉遣いの違和感 など）
【顧客側の感想】
・分かりやすい
・社内の開発チームでも使いたい など好感触

11. 今後について
毎週やり方を少しずつ改良しながら進めています
【今後の改善点】
・より可読性の高い記述方法の模索
・複数のモジュールやコンテキストを
跨いだシナリオテストの実施
・どこまでシナリオテストを作り込むかの見極め
→（例）代替シナリオ（ユースケース）
・画面を作るタイミングとのトレードオフ 等々

12. まとめ
ドメイン駆動設計を用いた受託開発
において
システムの仕様（期待する振る舞い）
を
顧客と合意する手段
として
（BDDをベースにした）シナリオテスト
を使ってみたらとても良い感じ