Downloaded 301 times
Uploaded by増田 亨
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動設計で、モデリングをどうやっているか、それをどう実装に結びつけているかの事例紹介。 RDRA+ICONXをベースに、より機敏なやり方への挑戦。実践的なオブジェクト指向設計。
ドメイン駆動で開発する ラフスケッチから実装まで
- 1.
- 2.
- 3.
- 4. 拙い設計 • コードが重複しまくっている • 条件分岐の密林があちこちにある •どこに何が書いてあるかわからない • 変更した時にどこで何が起きるか推測できない • やっていることは解読できるが、なぜ、そこでそ の処理が必要か意味がわからない • パッケージ名/クラス名/メソッド名/変数名/コメン トが嘘だらけ • でも動いてる 動いていなければ、ろくでもない設計であることは誰でもわかるのに… 4
- 5. 善い設計 • コードの重複がなくなる • 条件分岐の密林がなくなる •どこに何が書いてあるかわかりやすくなる • 変更した時に影響範囲を限定しやすくなる • 処理の意図がすぐわかる • パッケージ名/クラス名/メソッド名/変数名が わかりやすく正確になる – コメントはむしろノイズ 5 ドメイン駆動設計を実践すると、自然にこうなっていく
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. ドメイン駆動設計の手ごたえ • 対象領域の業務を学びながらソフトウェア 開発する面白さ • ソフトウェアが育っていく楽しさ •対象領域の知識とコードが一致している 時のコードのわかりやすさ • 変更が楽で安全になる気持ちよさ • 正しい仕事をしている安心感 12
- 13. ドメイン駆動設計のハードル • 発想の転換 – 「動いた」駆動から「善い設計」駆動へ –「技術」駆動から「ドメイン」駆動へ • 「善い設計」の判断基準の変化 • 設計・開発手法の切り替え – オブジェクト指向へ – インクリメンタルな設計へ • 実装の制約との戦い – フレームワークやプログラミング言語の制約 13 ここらへんの 実践経験を紹介します
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23. 最初にやっていたやり方 • モデルの作成に時間をかけた – モデリングツールの利用(EnterpriseArchitect) – クラス図 – ユースケース記述 – ロバストネス図 – ER図 • 慣れて来たら、なんでもかんでも図にすることはなく なった – 複雑になるところだけ – しっかり設計したいところだけ • 設計ドキュメントの作成が一段落してからコードを書い ていた 23
- 24.
- 25.
- 26. • オブジェクト指向がだんだん体になじんできた – 人間の関心事の表現と、ロジックの整理の単位（クラ ス）が一致してきた •インクリメンタルな設計の良さがだんだんわかっ てきた • ドメイン駆動設計って、もともとそういう本だよね、 そういえば – オブジェクト指向ソフトウエアの開発者向けに書いた – 設計と開発プロセスの議論の基礎としてエクストリー ムプログラミングを使用する 26
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. ９つのルール 1. 一つのメソッドでインデントは一段階 2. else句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 36
- 37. 名前をつける 1. 一つのメソッドでインデントは一段階 2. else句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 37 パッケージ クラス メソッド 小さい単位で 名前をつける
- 38. データとロジックを凝集させる 1. 一つのメソッドでインデントは一段階 2. else句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 38 値オブジェクト ファーストクラス コレクション データとロジックを別の場所におかない
- 39. 複数の関心事を持たない 1. 一つのメソッドでインデントは一段階 2. else句は使わない 3. すべてのプリミティブ型と文字列をラップする 4. 一行につきドットは１つまで 5. 名前を省略しない 6. すべてのエンティティを小さくする 7. 一つのクラスのインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter, setter, プロパティを使わない 39 ルールに違反している時は、複数の関心事が混在している
- 40.
- 41.
- 42. いやな臭い • コードが重複している • メソッドが長い •クラスが大きい • 引数が多い • データとロジックの置き場所が別のクラスに 分かれている 42
- 43. 設計の改善 • 名前の変更 – 業務の関心事と実装を一致させる •メソッドの抽出 – 手続きに名前をつける • クラスの抽出 – 手続きのグループに名前を付ける • メソッドの移動／フィールドの移動 – データとロジックの置き場所を同じクラスにする 43
- 44.
- 45.
- 46. レイヤ構造 • 三層構造ではなく、 三層＋ドメイン層 • O-Rマッピング –データクラス＋機能クラス（手続き型）になりがち なツールは避ける • JPA, Active Record, Entity Framework、… – オブジェクトが主役の軽量のツールを選ぶ • myBatis, Spring JDBCTemplate, … 46
- 47. プログラミング言語 • 静的な型付き言語 • 独自の型の定義 –標準ライブラリの型（クラス）は汎用的すぎる – 目的特化の型をどんどん作る • 型名を明記して意図を表現する – メソッドの返す型、メソッドの引数の型 – インスタンス変数の型 – ローカル変数の型 • 型の設計変更に強い – リファクタリングを楽に安全に 47
- 48.
- 49.
- 50. 基本方針 • ドメインオブジェクトをそのまま使う • 画面 –ドメインオブジェクトをHTMLにマッピング – HTTPリクエストをドメインオブジェクトにマッピング – Spring MVC/Thymeleaf • API – JSON<-> ドメインオブジェクトの自動マッピング – Spring MVC RestController / Jackson 50
- 51. 簡単にマッピングできない時 • ビュークラスを間にはさむ • 出力 –ビュークラスのコンストラクタにドメインオブジェクトを渡す • 入力 – 入力データからビュークラスを生成する – そのビュークラスにドメインオブジェクトのファクトリメソッド を用意する • ビュークラスは判断/加工/計算のロジックを持つ – DTOではない • 安易にビュークラスを導入しない – ドメインの関心事の表現（ドメインオブジェクト）とインタ フェースが不一致なのはおかしい 51
- 52.
- 53. 基本方針（構造） • アプリケーションクラスにデータソースクラスをイ ンジェクションする • Repositoryインタフェースを使って、データソース 層のクラスを隠ぺいする @Service classOrderService { @Autowired OrderRepository repository; void register( Order order ) { repository.register(order); } } 53
- 54. 基本方針 • 軽量の O-Rマッピングを使う ドメイン層をO-Rマッピングの仕組みで汚染しない – myBatis – Spring JDBCTemplate • JPAなど重量級のツールを使う場合 – データの入れ物クラス（@Entity)は、データソース層のクラ スとして宣言する – データソース層で、ドメインオブジェクトと@Entityクラスを 変換する – ドメインオブジェクトには、O-R マッピングのアノテーション を持ち込まない 54
- 55.
- 56.
- 57. 関心事を表現する基礎部品 ドメインオブジェクトの設計パターン • 値オブジェクト • 識別オブジェクト •ファーストクラスコレクション • 区分オブジェクト • How ではなくWhatを表現する • パッケージ 57
- 58.
- 59. 値オブジェクト • 業務の関心事の基本語彙 – 日付、期間、数量、金額、単位、名称、備考、… •ロジックの置き場所 – インスタンス変数として一つか二つの基本データ 型（文字列/数値/日付)を持つ – そのインスタンス変数を使った、判断・計算・加工 のロジックを一箇所に集める – コードの重複がなくなり、変更が楽になる 59
- 60. 値オブジェクト • ドメイン固有のString – PersonName,MailAddress, Telephone, … • ドメイン固有のint/long/BigDecimal – Money, Quantity, Rate, … • ドメイン固有のLocalDate – DueDate, ExpireDate, DateRange, … データの用途を明確にする（ドメインの言葉に一致させる 扱うデータの範囲を業務に合わせて限定する データの扱い方（メソッド）を業務に合わせて限定する 60
- 61. 値オブジェクト String List<String> BigDecimal Integer … LocalDate Long 起算日 InitialDate 期限 DueDate 有効期間ValidTerm 金額 Money 数量 Quantity 単位 Unit 品名 ProductName 備考 Remarks 摘要 Abstract 言語で用意された「型」 （汎用） 独自に定義した「型」 （目的特化） 61
- 62. 値オブジェクトの設計 • 完全コンストラクタ – すべてのインスタンス変数は、生成時に設定 •不変 – setter を書かない（状態を変えない） – 値を変更する時は、別のオブジェクトを生成して返す – 不変による「安定」 • ロジックの置き場所 – インスタンス変数を使った、判断・加工・計算 – 何もしないで素のデータを返す getter はNG 62
- 63.
- 64. 識別オブジェクト • 関心事を特定する • 人は何で特定するか –名前 – 生年月日 – メールアドレス … • コンピュータは何で特定するか – 一意の管理番号 – equals() • 両方の目的に使えるオブジェク トを作る 64
- 65.
- 66. ファーストクラスコレクション • ListやSetをラップしたドメインオブジェクト • PurchaseHistory •MailBox • SkillSet • 「一覧」や「履歴」という関心事の表現 – 「一覧」は利用者の関心事が集中する場所 – 「一覧」の議論は、重要な関心事の発見の良い機会 • コレクションの操作はコードがごちゃごちゃしや すく、変更の副作用が多い • クラスとして独立させ、そのクラスに閉じ込める 66
- 67.
- 68.
- 69. 区分オブジェクト • 振る舞いを持った Enum •Java言語使用に組み込まれた Strategy/Stateパターン + • 区分ごとのロジックを多態で記述 場合ごとのビジネスルールの表現 69
- 70. 区分オブジェクトの効果 • 複雑な if文記述の解消 –区分ごとの分岐記述( if文,switch文 )は一箇所に なる – 場合によっては、まったく書かなくてよい • どこに何が書いてあるかわかりやすくなる – 区分ごとのロジックをクラス単位で表現 • 区分の追加や削除をした時の、変更の副作 用が少ない（範囲を限定しやすい） 70
- 71.
- 72.
- 73.
- 74.
- 75. パッケージ • 利用者の関心事の「境界」を表現する手段 – 関連するドメインオブジェクト（の型）のグループ –プログラミング単位 – テスト単位 • 新しい発見とともに、積極的にパッケージ名 ／パッケージ構成を変更し育てていく • 「第４部 戦略的設計」の主要ツール 75
- 76.
- 77.
- 78.
- 79. サービスの会社が 業務システムに取り組む話 • アソビュー • 全国のレジャー・遊び・体験が探せる日本最大 級の検索・予約サイト •バックオフィス業務は必要最小限、かつ人間系 でがんばっているが… • 事業のさらなら発展のためには • バックオフィスのシステム充実が必須 • ただし、 • ビジネスモデルや業務フローは変わり続ける 79
- 80.
- 81.
- 82. 電子チケットサービス • アソビューの挑戦 – 金流の変更 •before : 主催会社にお金が入り、手数料を請求 • after: アソビューにお金が入り、主催会社に支払い – バックオフィス業務の複雑化 – 確実性や迅速性の要求 – バックオフィスシステムの開発経験不足 82
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93. インクリメンタルな設計 • このくらいの状態でコードを書き始める • 基本オブジェクトでロジックの置き場所を決める –値オブジェクト – ファーストクラスコレクション – 区分オブジェクト – 識別オブジェクト • アーキテクチャはテンプレートを使う – Spring Boot – 基本のレイヤ構造 presentation/application/domain/infrastructure 93
- 94.
- 95.
- 96.
- 97. ラフスケッチには登場しない ドメインオブジェクトの例 • Rate – 値オブジェクト –料率の計算ロジック • Amount – 値オブジェクト – 金額の四則演算 • DateRange – 値オブジェクト – 有効期間の設定と判定 • ValidType – 区分オブジェクト – チケットの状態区分と有効性の判定 最初から コードで書いて 成長させている 97
- 98. やってみた結果 • ２か月での迅速なリリース • その後、事業もシステムも順調に成長中 •企画部門や経営者から「チケットのような作り 方」に高い評価 • IT戦略としてのドメイン駆動設計の推進 98
- 99.
- 100.
- 101.
- 102.
- 103.