ドメイン駆動で開発する ラフスケッチから実装まで
•
38 j'aime•15,786 vues
ドメイン駆動設計で、モデリングをどうやっているか、それをどう実装に結びつけているかの事例紹介。 RDRA+ICONXをベースに、より機敏なやり方への挑戦。実践的なオブジェクト指向設計。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à ドメイン駆動で開発する ラフスケッチから実装まで
Similaire à ドメイン駆動で開発する ラフスケッチから実装まで (20)
Plus de 増田 亨
Plus de 増田 亨 (20)
ドメイン駆動で開発する ラフスケッチから実装まで
- 3. 設計の善し悪し 3
- 4. 拙い設計 • コードが重複しまくっている • 条件分岐の密林があちこちにある • どこに何が書いてあるかわからない • 変更した時にどこで何が起きるか推測できない • やっていることは解読できるが、なぜ、そこでそ の処理が必要か意味がわからない • パッケージ名/クラス名/メソッド名/変数名/コメン トが嘘だらけ • でも動いてる 動いていなければ、ろくでもない設計であることは誰でもわかるのに… 4
- 5. 善い設計 • コードの重複がなくなる • 条件分岐の密林がなくなる • どこに何が書いてあるかわかりやすくなる • 変更した時に影響範囲を限定しやすくなる • 処理の意図がすぐわかる • パッケージ名/クラス名/メソッド名/変数名が わかりやすく正確になる – コメントはむしろノイズ 5 ドメイン駆動設計を実践すると、自然にこうなっていく
- 12. ドメイン駆動設計の手ごたえ • 対象領域の業務を学びながらソフトウェア 開発する面白さ • ソフトウェアが育っていく楽しさ • 対象領域の知識とコードが一致している 時のコードのわかりやすさ • 変更が楽で安全になる気持ちよさ • 正しい仕事をしている安心感 12
- 13. ドメイン駆動設計のハードル • 発想の転換 – 「動いた」駆動から「善い設計」駆動へ – 「技術」駆動から「ドメイン」駆動へ • 「善い設計」の判断基準の変化 • 設計・開発手法の切り替え – オブジェクト指向へ – インクリメンタルな設計へ • 実装の制約との戦い – フレームワークやプログラミング言語の制約 13 ここらへんの 実践経験を紹介します
- 14. ドメイン駆動設計 14
- 19. どうすればよいか？ 19
- 21. こんな感じでやってみた 21
- 23. 最初にやっていたやり方 • モデルの作成に時間をかけた – モデリングツールの利用(Enterprise Architect) – クラス図 – ユースケース記述 – ロバストネス図 – ER図 • 慣れて来たら、なんでもかんでも図にすることはなく なった – 複雑になるところだけ – しっかり設計したいところだけ • 設計ドキュメントの作成が一段落してからコードを書い ていた 23
- 24. がんばって設計したつもりなのに あいかわらず修正や拡張は たいへんだった コード 汚い ／ 変更 やっかい 24
- 26. • オブジェクト指向がだんだん体になじんできた – 人間の関心事の表現と、ロジックの整理の単位（クラ ス）が一致してきた • インクリメンタルな設計の良さがだんだんわかっ てきた • ドメイン駆動設計って、もともとそういう本だよね、 そういえば – オブジェクト指向ソフトウエアの開発者向けに書いた – 設計と開発プロセスの議論の基礎としてエクストリー ムプログラミングを使用する 26
- 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 ルールに違反している時は、複数の関心事が混在している
- 42. いやな臭い • コードが重複している • メソッドが長い • クラスが大きい • 引数が多い • データとロジックの置き場所が別のクラスに 分かれている 42
- 43. 設計の改善 • 名前の変更 – 業務の関心事と実装を一致させる • メソッドの抽出 – 手続きに名前をつける • クラスの抽出 – 手続きのグループに名前を付ける • メソッドの移動／フィールドの移動 – データとロジックの置き場所を同じクラスにする 43
- 46. レイヤ構造 • 三層構造ではなく、 三層＋ドメイン層 • O-Rマッピング – データクラス＋機能クラス（手続き型）になりがち なツールは避ける • JPA, Active Record, Entity Framework、… – オブジェクトが主役の軽量のツールを選ぶ • myBatis, Spring JDBCTemplate, … 46
- 47. プログラミング言語 • 静的な型付き言語 • 独自の型の定義 – 標準ライブラリの型（クラス）は汎用的すぎる – 目的特化の型をどんどん作る • 型名を明記して意図を表現する – メソッドの返す型、メソッドの引数の型 – インスタンス変数の型 – ローカル変数の型 • 型の設計変更に強い – リファクタリングを楽に安全に 47
- 50. 基本方針 • ドメインオブジェクトをそのまま使う • 画面 – ドメインオブジェクトをHTMLにマッピング – HTTPリクエストをドメインオブジェクトにマッピング – Spring MVC/Thymeleaf • API – JSON<-> ドメインオブジェクトの自動マッピング – Spring MVC RestController / Jackson 50
- 51. 簡単にマッピングできない時 • ビュークラスを間にはさむ • 出力 – ビュークラスのコンストラクタにドメインオブジェクトを渡す • 入力 – 入力データからビュークラスを生成する – そのビュークラスにドメインオブジェクトのファクトリメソッド を用意する • ビュークラスは判断/加工/計算のロジックを持つ – DTOではない • 安易にビュークラスを導入しない – ドメインの関心事の表現（ドメインオブジェクト）とインタ フェースが不一致なのはおかしい 51
- 53. 基本方針（構造） • アプリケーションクラスにデータソースクラスをイ ンジェクションする • Repositoryインタフェースを使って、データソース 層のクラスを隠ぺいする @Service class OrderService { @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
- 57. 関心事を表現する基礎部品 ドメインオブジェクトの設計パターン • 値オブジェクト • 識別オブジェクト • ファーストクラスコレクション • 区分オブジェクト • How ではなくWhatを表現する • パッケージ 57
- 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
- 64. 識別オブジェクト • 関心事を特定する • 人は何で特定するか – 名前 – 生年月日 – メールアドレス … • コンピュータは何で特定するか – 一意の管理番号 – equals() • 両方の目的に使えるオブジェク トを作る 64
- 66. ファーストクラスコレクション • ListやSetをラップしたドメインオブジェクト • PurchaseHistory • MailBox • SkillSet • 「一覧」や「履歴」という関心事の表現 – 「一覧」は利用者の関心事が集中する場所 – 「一覧」の議論は、重要な関心事の発見の良い機会 • コレクションの操作はコードがごちゃごちゃしや すく、変更の副作用が多い • クラスとして独立させ、そのクラスに閉じ込める 66
- 69. 区分オブジェクト • 振る舞いを持った Enum • Java言語使用に組み込まれた Strategy/Stateパターン + • 区分ごとのロジックを多態で記述 場合ごとのビジネスルールの表現 69
- 70. 区分オブジェクトの効果 • 複雑な if文記述の解消 – 区分ごとの分岐記述( if文,switch文 )は一箇所に なる – 場合によっては、まったく書かなくてよい • どこに何が書いてあるかわかりやすくなる – 区分ごとのロジックをクラス単位で表現 • 区分の追加や削除をした時の、変更の副作 用が少ない（範囲を限定しやすい） 70
- 72. expireDate.add(-1); expireDate.previousDay(); expireDate.dayOfFinalAlert (); 業務要件：期限切れの前日にアラートメールを送る How より What 業務の関心事を明示的に表現する 72
- 75. パッケージ • 利用者の関心事の「境界」を表現する手段 – 関連するドメインオブジェクト（の型）のグループ – プログラミング単位 – テスト単位 • 新しい発見とともに、積極的にパッケージ名 ／パッケージ構成を変更し育てていく • 「第４部 戦略的設計」の主要ツール 75
- 76. パッケージ図を使った ロジックの置き場所の俯瞰 76 与信限度額を考慮するとどうなるか？ 発注と仕入れまで視野を広げるとどうなるか？ 矢印で示した一方向の依存関係で正しく実装しているか／実装できるか？
- 79. サービスの会社が 業務システムに取り組む話 • アソビュー • 全国のレジャー・遊び・体験が探せる日本最大 級の検索・予約サイト • バックオフィス業務は必要最小限、かつ人間系 でがんばっているが… • 事業のさらなら発展のためには • バックオフィスのシステム充実が必須 • ただし、 • ビジネスモデルや業務フローは変わり続ける 79
- 82. 電子チケットサービス • アソビューの挑戦 – 金流の変更 • before : 主催会社にお金が入り、手数料を請求 • after: アソビューにお金が入り、主催会社に支払い – バックオフィス業務の複雑化 – 確実性や迅速性の要求 – バックオフィスシステムの開発経験不足 82
- 83. そこで ドメイン駆動設計 83
- 92. 関心事をざくっと整理する 92
- 93. インクリメンタルな設計 • このくらいの状態でコードを書き始める • 基本オブジェクトでロジックの置き場所を決める – 値オブジェクト – ファーストクラスコレクション – 区分オブジェクト – 識別オブジェクト • アーキテクチャはテンプレートを使う – Spring Boot – 基本のレイヤ構造 presentation/application/domain/infrastructure 93
- 97. ラフスケッチには登場しない ドメインオブジェクトの例 • Rate – 値オブジェクト – 料率の計算ロジック • Amount – 値オブジェクト – 金額の四則演算 • DateRange – 値オブジェクト – 有効期間の設定と判定 • ValidType – 区分オブジェクト – チケットの状態区分と有効性の判定 最初から コードで書いて 成長させている 97
- 98. やってみた結果 • ２か月での迅速なリリース • その後、事業もシステムも順調に成長中 • 企画部門や経営者から「チケットのような作り 方」に高い評価 • IT戦略としてのドメイン駆動設計の推進 98
- 99. 本日のまとめ 99