1. BMC 西 秀和
2015/06/18
BIGLOBE×DDD
実践編

2. 自己紹介
• 西 秀和（３３歳）
• 経営管理センター(BMC) 主任
• ビックローブで勤務
• ビックローブ光 開発チーム
(リードエンジニア)

3. 光戦争勃発

4. 6400円 4980円
3750〜4500円
一戸建ての場合
集合住宅の場合
3980円※たぶん
フレッツから乗り換えると、
月額料金がだいたいお得!!

5. 太陽系戦略
Wifi
０A0
モバイル
コラボ関連会員
VAS特典
商品契約
トリトン
冥王星
海王星
土星
木星
火星地球
ドメイン駆動設計の拡大
認証
金星
現状：弊社の現場におけるDDD
第二
世代
時間軸：2年
この辺りの領域で探す

6. 1. DDDを適用するサービスを決める
2. DDD適用のためのチームを作る
3. 実践する
4. 障害が起きる
5. まとめ
実践編

7. 1.適用するサービ
スを決める

8. DDDの利点って？
• 変更コストを下げる
• 業務知識をドメイン(コード)に貯め
る
• エンジニアの視点をユーザ視点に戻
す

9. 既存のサービス
仕様追加・変更が多い
改造しづらいと感じている
選定基準
独立性が高い

11. 携帯を使いすぎると
遅くなるアレ
帯域制御

12. うれスマ用
制御
システム
パケット
使用量 帯域抑制
帯域
制御装置
200kbps
最高速度
最高速度
うれスマ Xi回線
うれスマ通信制御

13. 主なサービス仕様
３日間(７２時間)のパケット量でも制限がかかる
上限を超えたら、ボリュームチャージ(300円/100M)
月々に利用できるパケット量が異なるプランを提供

14. ISP業界をとりまく環境

15. 2.専用チームを作る

16. なぜ専用チーム？
• 全員で設計する
• プロセスではなく考え方を変え
たい
• 既存の業務が邪魔

17. 3rdチームB1stチーム
3rdチームC
3rdチームA
2ndチームC
2ndチームB
2ndチームA
Aサービス
1
6
2
7
3
8
4
共通ライブラリ
Bサービス
1
2 3
5 1
2
4
Cサービス
退社

18. 3.実践する

19. ユーザインタフェース層
(api層)
アプリケーション層
(service層)
ドメイン層
インフラストラクチャ層
(datasource層)
パッケージ構成
REST⇔ドメインの変換
業務を組み立てる
ドメインモデル
データベース⇔ドメインの変換
まずはココから

20. まずは
ドメインモデル
を作る

21. チームの中心となる
共通認識
が必要

23. やり方
手段 ：ホワイトシートと付箋
参加者：チームメンバ全員で作業（大切）
時間 ：１〜２時間程度
[手順]
1. ValueObject(単一のデータ)に名前をつける
2. Entity(データ集まり)に名前をつける
3. 状態(ステータス)を見つける
4. ユースケースごとにEntityのライフサイクルを考えてみる

24. 636クラス
13テーブル

25. ユースケースフロー
を考える

26. ユースケースフロー図

27. 手段 ：ホワイトシートと付箋
参加者：チームメンバ全員で作業（大切）
時間 ：特に決めない
やり方
ユースケース単位に
どのEntityが
何の業務(役割)をするのかを確認
目的
アプリケーション(service)層の設計

28. データベースを
考える

29. 手段 ：ホワイトシートと付箋
参加者：チームメンバ全員で作業（大切）
時間 ：特に決めない
単位 ：Entity単位に設計
※必要なDB項目は全てこのタイミングで洗い出す
やり方

30. 設計方針
state(マスタ)テーブル と history(履歴)テーブル
※update中心の考え方
このプロジェクトで設計方針を変更
eventテーブル と 補助的にstate(マスタ)テーブル
※insert中心(イミュータブルデータモデル)
業務を中心に考えると、
event毎にデータが残る方が自然

31. スケルトンコードを
書いてみる

32. ユーザインタフェース層
(api層)
アプリケーション層
(service層)
ドメイン層
インフラストラクチャ層
(datasource層)
パッケージ構成
REST⇔ドメインの変換
業務を組み立てる
ドメインモデル
データベース⇔ドメインの変換

33. スケルトンコードとは？
• 中身のない(骨組みだけの)クラスだけのコード
• はじめは、ドメイン層のみ作成
目的は？
• クラス設計の代わり(クラス図は面倒だった)
• 意外とドメインモデルの修正もある

34. 実装してみる

35. 1. インフラストラクチャ層
2. Fixture(テストデータ)の準備
3. アプリケーション層 & ドメイン層
4. ユーザインタフェース層
作成順
api
(ユースケース)
単位
Entity
(業務データ)
単位

36. 21
19
40
32
8
23
35
31
27
0
11
0
10
20
30
40
50
SP
夏休み
Sprint毎ストーリーポイント
リリース
インフラストラクチャー層作成
アプリケーション層
最後の仕上げ

37. インフラストラクチャー層は予定通り進まない
アプリケーション層を組み上げるのは楽しい。
ドメインが一番成長する工程
テストデータは初めに用意した方がいい
ドメインモデルを修正する事を忘れがち
データモデル⇔ドメインモデルの変換が難しい
個人的な感想
アプリケーション層
インフラストラクチャー層

38. リリースしてみる

39. 4.障害が起きる

40. リリース日
障害４件

41. この日のFaceBook
障害が
起きても
大丈夫

42. 僕らには
ドメインモデル
（共通認識）
がある

44. 障害対応では
チーム力が問われる
問題がある場所
問題による影響
同様な問題への横展開
メンバ全員が正確に把握

45. 5.まとめ

46. DDDを適用するサービス
会社が(ビジネスとして)
力を入れているサービス

47. [のれん分け方式]
チームを分けて、
それぞれに人を追加する
変えたいのは、
プロセスではなく考え方
チームの拡大

48. 設計に関わることは
チーム全員でやる
チームの共通認識を
育てることが大事
実践その１

49. 設計のアウトプットには力を入れない
（ホワイトシートで十分）
業務知識を
正しく・等しく
捉えることが大切
実践その２

50. 障害は出したらダメ
実践その３
障害はチーム力が試される

51. ご静聴
ありがとう
ございました