劇的ビフォーアフター〜BIGLOBEのDDDの昔と今〜 in 大阪
•Download as PPTX, PDF•
2 likes•1,397 views
https://yahoo-osaka.connpass.com/event/138020/
More Related Content
What's hot
What's hot (20)
Similar to 劇的ビフォーアフター〜BIGLOBEのDDDの昔と今〜 in 大阪
Similar to 劇的ビフォーアフター〜BIGLOBEのDDDの昔と今〜 in 大阪 (20)
劇的ビフォーアフター〜BIGLOBEのDDDの昔と今〜 in 大阪
- 2. BIGLOBE Inc.2 自己紹介 名前：曽根 大作（そね だいさく） ・30歳 ・2012年度入社の8年目 ・認定スクラムマスター(CSM) 所属・担当業務 ・基盤本部 サービス開発部 ・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〜 ドメインモデル - UCの処理を表すモデル - 各エンティティの関連や多重度を表す - 振る舞いは記載する（引数と返却値） - イメージはナビ -> 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〜 解決策 - DomainServiceを作成 - チェックに必要な業務ロジックを集約する - Domain層で業務ロジックを表現する
- 55. BIGLOBE Inc.55 チェック 〜AFTER〜 やり方を変えてよかったこと - 業務ロジックとそれ以外が分離できて、読みやすい - 処理の流れと業務ロジックのそれぞれでテストが行 える
- 59. BIGLOBE Inc.
Editor's Notes
- アンケートを取る
- Xmlがベースの言語 エディターで開発、エラーが実行時しか判断できない typoも実行時にしかエラーがでない メソッドの仕様がエクセルに 資料が古い
- 安西さん、増田さん