劇的ビフォーアフター 〜BIGLOBEのDDDの昔と今〜
•Download as PPTX, PDF•
1 like•802 views
https://genbade-ddd.connpass.com/event/127494/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 劇的ビフォーアフター 〜BIGLOBEのDDDの昔と今〜
Similar to 劇的ビフォーアフター 〜BIGLOBEのDDDの昔と今〜 (20)
劇的ビフォーアフター 〜BIGLOBEのDDDの昔と今〜
- 2. BIGLOBE Inc.2 自己紹介 名前：曽根 大作（そね だいさく） ・30歳 ・2012年度入社の8年目 所属・担当業務 ・基盤本部 サービス開発部 ・BIGLOBEモバイル(格安SIM)の業務システム開発
- 12. BIGLOBE Inc.12 モデルの書き方 モデルに表したいこと - 業務とコードを一致させる - エンティティの責務を表す - エンティティ同士の関連を表現する - etc . . .
- 14. BIGLOBE Inc.14 モデルの書き方 〜BEFORE〜 当時のやりかた 1. サービスの仕様書から名詞を抽出 2. グルーピング 3. グループに名前をつける 4. キーが必要かどうかを考える - 必要＝エンティティ - 不要＝アグリゲート
- 15. BIGLOBE Inc.15 モデルの書き方 〜BEFORE〜 例：モバイルサービスを申し込んで、契約する ・会員には以下の情報が必要 - 氏名 - 住所 - 生年月日 ・ 申し込みに以下の情報が必要 - プラン(月間の容量) - SIMカードのサイズと種別 ・ 申し込まれたらSIMカードを配送する
- 17. BIGLOBE Inc.17 モデルの書き方 〜BEFORE〜 問題点 - 情報不足による認識齟齬多発 - 関連がないため処理の流れをイメージできない - エンティティの責務や振る舞いがわからない ・・・？
- 18. BIGLOBE Inc. 結果 - Pull Requestが大荒れ - コメント3桁超え - 認識齟齬が起きてマージされない - 設計や責務の話 - 指摘ではなく質問が多い 18 モデルの書き方 〜BEFORE〜
- 20. BIGLOBE Inc. 解決策 - 情報を増やす - 責務 - 関連や依存 - 多重度 - 振る舞い - 値 20 モデルの書き方 〜AFTER〜
- 21. BIGLOBE Inc. １枚の図にすべてを表そうとするのは無理 - 何を伝えたい図なのか分からなくなる - 好き勝手に修正される or 修正されない 21 モデルの書き方 〜AFTER〜
- 23. BIGLOBE Inc.23 モデルの書き方 〜AFTER〜 概念モデル - システム全体を表すモデル - 代表的なエンティティのみの関連や多重度を表す - 振る舞いなどは書かない - イメージは世界地図
- 25. BIGLOBE Inc.25 モデルの書き方 〜AFTER〜 コンテキストマップ - 概念モデルで表現したエンティティの境界を表す - エンティティとシステムのマッピング - 振る舞いなどは書かない - イメージは大陸
- 27. BIGLOBE Inc.27 モデルの書き方 〜AFTER〜 ドメインモデル - ユースケースの処理を表すモデル - 各エンティティの関連などを表す - 振る舞いを記載する - イメージはナビ -> AからBまで何を使ってたどり着くか
- 29. BIGLOBE Inc.29 モデルの書き方 〜AFTER〜 やり方を変えてよかったこと - 目的に合わせてモデルを変えることで、認識齟齬が 起きにくくなった - Pull Requestで設計の話が出てこなくなった -> 実装の良し悪しに集中することができる
- 30. BIGLOBE Inc.30 モデルの書き方 〜AFTER〜 今の問題点 - 概念モデルやコンテキストマップからドメインモデ ルを作るのが大変 考えている解決策 - 間にもう1つモデルがほしい - イメージ的には日本地図ぐらいの粒度
- 33. BIGLOBE Inc.33 状態の表し方 状態を管理する 申込中 契約中 解約 契約 どうやって表現するか？
- 37. BIGLOBE Inc.37 状態の表し方 〜BEFORE〜 問題点 - エンティティの肥大化 - 全てのイベントの全てのフィールドに getter が必要 - ロジックが集中してしまう - 不要なフィールドを意識する必要がある
- 38. BIGLOBE Inc.38 状態の表し方 〜BEFORE〜 結果 -エンティティの行数が数百行に -生成コストが高い - フィールドにOptionalが増える - 不要なイベントを意識する必要がある
- 40. BIGLOBE Inc.40 状態の表し方 〜AFTER〜 解決策 - 状態ごとに必要な要素のみを持ったエンティティを 生成
- 42. BIGLOBE Inc.42 状態の表し方 〜AFTER〜 やり方を変えて良かったこと - エンティティの責務がはっきりする - 不要なメソッドやフィールドがなくなる - エンティティが小さくなる
- 43. BIGLOBE Inc.43 状態の表し方 〜AFTER〜 今の問題点 - クラス数の増大 - ほぼ同じ内容の用途違いのクラスが増える - 重複コードも増える - 名前が長くなる（〇〇のための〇〇みたいな）
- 44. BIGLOBE Inc.44 状態の表し方 〜AFTER〜 解決策 - 検討中・・・。
- 47. BIGLOBE Inc.47 チェック チェックの設計について - 様々な業務ロジックをどのように表現するか？ - 例：20歳以上 ：契約中じゃないと申し込めない
- 51. BIGLOBE Inc.51 チェック 〜BEFORE〜 問題点 - Application層に業務ロジックが書かれている - 業務以外のロジックと混ざるため、可読性が低い - テストが複雑になる
- 53. BIGLOBE Inc.53 チェック 〜AFTER〜 解決策 - Domainで業務ロジックを表現する - Domain層に DomainService を作成する - チェックに必要な業務ロジックを集約する
- 55. BIGLOBE Inc.55 チェック 〜AFTER〜 やり方を変えてよかったこと - 業務ロジックとそれ以外が分離できて、読みやすい - 処理の流れと業務ロジックのそれぞれでテストが行 える
- 60. BIGLOBE Inc.
Editor's Notes
- 格安SIMのアンケートを取る
- BIGLOBEがDDDを導入した当時と今を比較して、どのように変わっていたのかをお話していこうと思います。
- ・独自言語 XMLベースの独自言語 テキストエディタで開発 ・マニュアル どこにあるかわからない メンテされてない
- そんなレガシーなものを駆逐するため
- まっさらな新規：wifi 既存の部分に新規サービスの追加：mobile
- 申込中から業務が発生して契約中に状態が遷移する
- 契約エンティティは一種類 状態やイベントを調査するときは、契約エンティティ経由でアクセスする
- 契約リポジトリに問い合わせれば様々な状態の契約を取得することができる
- アンケート