Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Biglobe×ddd 実践編(dev love 20150618)

3,731 views

Published on

Published in: Software

Biglobe×ddd 実践編(dev love 20150618)

  1. 1. BMC 西 秀和 2015/06/18 BIGLOBE×DDD 実践編
  2. 2. 自己紹介 • 西 秀和(33歳) • 経営管理センター(BMC) 主任 • ビックローブで勤務 • ビックローブ光 開発チーム (リードエンジニア)
  3. 3. 光戦争勃発
  4. 4. 6400円 4980円 3750〜4500円 一戸建ての場合 集合住宅の場合 3980円※たぶん フレッツから乗り換えると、 月額料金がだいたいお得!!
  5. 5. 太陽系戦略 Wifi 0A0 モバイル コラボ関連会員 VAS特典 商品契約 トリトン 冥王星 海王星 土星 木星 火星地球 ドメイン駆動設計の拡大 認証 金星 現状:弊社の現場におけるDDD 第二 世代 時間軸:2年 この辺りの領域で探す
  6. 6. 1. DDDを適用するサービスを決める 2. DDD適用のためのチームを作る 3. 実践する 4. 障害が起きる 5. まとめ 実践編
  7. 7. 1.適用するサービ スを決める
  8. 8. DDDの利点って? • 変更コストを下げる • 業務知識をドメイン(コード)に貯め る • エンジニアの視点をユーザ視点に戻 す
  9. 9. 既存のサービス 仕様追加・変更が多い 改造しづらいと感じている 選定基準 独立性が高い
  10. 10. 携帯を使いすぎると 遅くなるアレ 帯域制御
  11. 11. うれスマ用 制御 システム パケット 使用量 帯域抑制 帯域 制御装置 200kbps 最高速度 最高速度 うれスマ Xi回線 うれスマ通信制御
  12. 12. 主なサービス仕様 3日間(72時間)のパケット量でも制限がかかる 上限を超えたら、ボリュームチャージ(300円/100M) 月々に利用できるパケット量が異なるプランを提供
  13. 13. ISP業界をとりまく環境
  14. 14. 2.専用チームを作る
  15. 15. なぜ専用チーム? • 全員で設計する • プロセスではなく考え方を変え たい • 既存の業務が邪魔
  16. 16. 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サービス 退社
  17. 17. 3.実践する
  18. 18. ユーザインタフェース層 (api層) アプリケーション層 (service層) ドメイン層 インフラストラクチャ層 (datasource層) パッケージ構成 REST⇔ドメインの変換 業務を組み立てる ドメインモデル データベース⇔ドメインの変換 まずはココから
  19. 19. まずは ドメインモデル を作る
  20. 20. チームの中心となる 共通認識 が必要
  21. 21. やり方 手段 :ホワイトシートと付箋 参加者:チームメンバ全員で作業(大切) 時間 :1〜2時間程度 [手順] 1. ValueObject(単一のデータ)に名前をつける 2. Entity(データ集まり)に名前をつける 3. 状態(ステータス)を見つける 4. ユースケースごとにEntityのライフサイクルを考えてみる
  22. 22. 636クラス 13テーブル
  23. 23. ユースケースフロー を考える
  24. 24. ユースケースフロー図
  25. 25. 手段 :ホワイトシートと付箋 参加者:チームメンバ全員で作業(大切) 時間 :特に決めない やり方 ユースケース単位に どのEntityが 何の業務(役割)をするのかを確認 目的 アプリケーション(service)層の設計
  26. 26. データベースを 考える
  27. 27. 手段 :ホワイトシートと付箋 参加者:チームメンバ全員で作業(大切) 時間 :特に決めない 単位 :Entity単位に設計 ※必要なDB項目は全てこのタイミングで洗い出す やり方
  28. 28. 設計方針 state(マスタ)テーブル と history(履歴)テーブル ※update中心の考え方 このプロジェクトで設計方針を変更 eventテーブル と 補助的にstate(マスタ)テーブル ※insert中心(イミュータブルデータモデル) 業務を中心に考えると、 event毎にデータが残る方が自然
  29. 29. スケルトンコードを 書いてみる
  30. 30. ユーザインタフェース層 (api層) アプリケーション層 (service層) ドメイン層 インフラストラクチャ層 (datasource層) パッケージ構成 REST⇔ドメインの変換 業務を組み立てる ドメインモデル データベース⇔ドメインの変換
  31. 31. スケルトンコードとは? • 中身のない(骨組みだけの)クラスだけのコード • はじめは、ドメイン層のみ作成 目的は? • クラス設計の代わり(クラス図は面倒だった) • 意外とドメインモデルの修正もある
  32. 32. 実装してみる
  33. 33. 1. インフラストラクチャ層 2. Fixture(テストデータ)の準備 3. アプリケーション層 & ドメイン層 4. ユーザインタフェース層 作成順 api (ユースケース) 単位 Entity (業務データ) 単位
  34. 34. 21 19 40 32 8 23 35 31 27 0 11 0 10 20 30 40 50 SP 夏休み Sprint毎ストーリーポイント リリース インフラストラクチャー層作成 アプリケーション層 最後の仕上げ
  35. 35. インフラストラクチャー層は予定通り進まない アプリケーション層を組み上げるのは楽しい。 ドメインが一番成長する工程 テストデータは初めに用意した方がいい ドメインモデルを修正する事を忘れがち データモデル⇔ドメインモデルの変換が難しい 個人的な感想 アプリケーション層 インフラストラクチャー層
  36. 36. リリースしてみる
  37. 37. 4.障害が起きる
  38. 38. リリース日 障害4件
  39. 39. この日のFaceBook 障害が 起きても 大丈夫
  40. 40. 僕らには ドメインモデル (共通認識) がある
  41. 41. 障害対応では チーム力が問われる 問題がある場所 問題による影響 同様な問題への横展開 メンバ全員が正確に把握
  42. 42. 5.まとめ
  43. 43. DDDを適用するサービス 会社が(ビジネスとして) 力を入れているサービス
  44. 44. [のれん分け方式] チームを分けて、 それぞれに人を追加する 変えたいのは、 プロセスではなく考え方 チームの拡大
  45. 45. 設計に関わることは チーム全員でやる チームの共通認識を 育てることが大事 実践その1
  46. 46. 設計のアウトプットには力を入れない (ホワイトシートで十分) 業務知識を 正しく・等しく 捉えることが大切 実践その2
  47. 47. 障害は出したらダメ 実践その3 障害はチーム力が試される
  48. 48. ご静聴 ありがとう ございました

×