![抽象データ型の例
内部のデータ表現 公開メソッド（やってほしいこと）
String char[] value String substring()
String[] split()
String replace()
…
BigDecimal BigInteger intVal ( ⇒ int[] )
int scale
BigDecimal add()
BigDecimal[] divideAndRemainder()
BigDecimal setScale()
…
LocalDate int year
short month
short day
LocalDate plusDays()
LocalDate minusMonths()
boolean isBefore()
…
ArrayList Object[] elementData
int size
boolean add()
boolean contains()
…](https://image.slidesharecdn.com/domain-objects-160525131742/85/-14-320.jpg)
More Related Content
What's hot (20)
Similar to ドメインオブジェクトの見つけ方・作り方・育て方 (20)
More from 増田 亨 (20)
ドメインオブジェクトの見つけ方・作り方・育て方
- 3. オブジェクト指向設計の 考え方とやり方 オブジェクト指向エクササイズ ９つのルール モジュール性 ５つの基準 抽象データ型 契約による設計 コードのいやな臭い その改善策１章 ドメインを学ぶ ２章 言葉を使う ３章 モデルと実装を結びつける ４章 ドメインを隔離する ５章 モデルを表現する部品 １０章 しなやかな設計 ４冊とも、想定読者はオブジェクト指向でコードを書く人 それぞれが関連している 今日は実践例として紹介してみたい
- 4. ドメインオブジェクト 設計の基本 ・モジュール性 凝集と結合 ・オブジェクト指向によるモジュール性 見つけ方 ・ドメインを学ぶ ・とりあえずのひな型 ・ドメインオブジェクトの発見パターン 作り方 ・主役は値オブジェクト ・ドメインを隔離する ・オブジェクト指向エクササイズ ９つのルール 育て方 ・リファクタリング いやな臭いと改善策 ・振る舞いを豊かにする７つの視点 ・しなやかな設計 ６つのパターン
- 5. ４冊に共通する価値観 変化を続ける 変更容易性 複雑さと戦う そのための技法が、オブジェクト指向でありエクストリームプログラミング ４冊は、強調する点、抽象度、表現が異なるが、同じ考え方が底流にある
- 6. オブジェクト指向の開発スタイル Iterative 小さく繰り返す Incremental +1 : 一度に少しずつ変化させる Interactive 意思の疎通を図りながら Synergy ３つの “I” の相乗効果 （足し算ではなく掛け算） 変更容易性を重視した設計技法の必然の開発スタイル 「変更」を予防する／管理する技法とは対照的な発想
- 12. 機能分割：機能クラスとデータクラス • C言語や COBOLの設計スタイルを、Java に流用 • JavaBeans getter/setter – データの入れ物クラスの設計パターン – get する側のクラスに機能を記述する • JPA @Entity – Java Beans をテーブルとのマッピングに利用 （データモジュール） – 機能は、ロジッククラスに記述する （機能モジュール） • トランザクションスクリプト • ファットコントローラ／ファットサービス
- 13. オブジェクト指向：抽象データ型 • メイヤー流の「型」重視のオブジェクト指向 • 使う側から見た抽象データ型 – 必要な判断・加工・計算を内部で実行して、その 「結果」を返してくれる – 内部をどのように実装しているかは非公開 • 抽象データ型の内部 – 具体的なデータ表現（非公開） – そのデータを使った、判断・加工・計算のロジック の記述
- 14. 抽象データ型の例 内部のデータ表現 公開メソッド（やってほしいこと） String char[] value String substring() String[] split() String replace() … BigDecimal BigInteger intVal ( ⇒ int[] ) int scale BigDecimal add() BigDecimal[] divideAndRemainder() BigDecimal setScale() … LocalDate int year short month short day LocalDate plusDays() LocalDate minusMonths() boolean isBefore() … ArrayList Object[] elementData int size boolean add() boolean contains() …
- 15. モジュール性の比較 基準 機能分割 機能クラス＋データクラス オブジェクト指向 抽象データ型 分解しやすい ○ ○ 組合せやすい × 分解時の構造に依存 ○ 分解時の構造に依存しない わかりやすい × 呼び出し元や呼び出し先を調べる 必要がある ○ 独立性が高い 連続性 × ひとつの変更が、複数個所に波及 する（コードの分散） ○ 関心事と実装の単位が整合している 保護性 × 呼び出し関係に沿って伝播する ○ 閉じ込めやすい 簡単に言えば 変更が楽で安全なのがオブジェクト指向 変更がたいへんで危険なのが機能分割
- 16. オブジェクト指向のモジュール性 • 難しい理屈から理解するのはたいへん – 学び方として、費用対効果が悪い • 実際にやってみる – オブジェクト指向らしいコードを書いてみて、変更が楽で 安全になることを体験するのが一番 ⇒ オブジェクト指向エクササイズ ９つのルール ⇒ リファクタリング いやな臭いとその改善 ⇒ ドメイン駆動設計 10章しなやかな設計の6パターン • いちど味を覚えると元の世界にはもどれない – わかりやすい – 連続性 – 組合せやすい 知っておいて損はない こっちが好きな人はこちらからどうぞｗ
- 18. オブジェクト指向エクササイズ 1. １つのメソッドにインデントは１段階まで 2. else 句は使わない 3. すべての基本データ型をラップする 4. １行につきドットはひとつまで 5. 名前を省略しない 6. ５０行を超えるクラスを作らない 7. １つにクラスはインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter / setter を使わない このガイドラインにそってコードを書けばモジュール性を向上できる
- 19. リファクタリング いやな臭い 1. 重複したコード 2. 長いメソッド 3. 大きなクラス 4. 多すぎる引数 5. 基本データ型への執着 6. データクラス 7. switch 文 8. コメント … モジュール性が悪くなっている明らかな兆候 リファクタリングによる改善 ・メソッドの抽出 ・クラスの抽出 ・メソッドの移動 ・メソッドオブジェクト 一つのメソッドにインデントは１段階まで 50行を超えるクラスを書かない ひとつのクラスのインスタンス変数は２つまで すべての基本データ型をラップする getter/setter を書かない ファーストクラスコレクションを使う else句を使わない
- 20. ドメイン駆動設計 しなやかな設計 1. 意図の明確なインタフェース 2. 副作用のない関数 3. 表明 4. 概念の輪郭 5. 独立したクラス 6. 閉じた操作 １０章の６つのパターン わかりやすい 組み立てやすい 分けやすさ 保護性 わかりやすい 連続性（モデルと実装の構造の一致） モジュール性を改善するための基本テクニック ５章の 値オブジェクトの設計パターンでもある
- 21. 設計の基本：まとめ • 設計の基本は「モジュール性」 • オブジェクト指向のモジュール性は 「抽象データ型」で実現する – データクラス＋機能クラスは、手続き型のモ ジュール性 • 理屈よりも実践で覚えるのが楽で確実 – オブジェクト指向エクササイズ ９つのルール – リファクタリング いやな臭いとその改善 – ドメイン駆動設計 １０章しなやかな設計
- 26. トップページ ヘルプ 利用規約
- 27. 全体図＋用語の洗い出し
- 32. これらについて「名前」を探す
- 34. 関心事の種類と見つけ方 Aspect 知りたいこと それが何であるか which, what, when, where 画面や帳票から具体的に見つけやすい Why ６つの関係 約束と履行 方針と規則 判断や行動の理由づけ 業務知識の中核 見つけにくい ここを深く理解し、コードでうまく表現するこ とがドメイン駆動設計の勝負どころ How 記録と参照 約束と履行の監視 業務の基本 要求は表面的 より突っ込んだ設計が必要 勘定パターンを参考に 通知 受信と送信 業務の流れ 具体的な要求として見つかりやすい whyの 実行手段 性状 枠組み 制約
- 35. 性状(aspect) : 知りたいこと which 識別 Identity 名前、番号 Category 名前 Type 名前 what 値 数量、金額、率 説明、注釈 状態 when 時 日付 期間 where 位置 Address Location Area 物理、論理、仮想 知りたいことに「名前」をつけ 基本データ型（文字列型、数値型、日付型）で表現する それが、値オブジェクト 絶対／相対
- 36. why の設計パターン 外部との約束 「注文」は売買契約の一種 キンセャルポリシー etc. 内部の取り決め（生産や開発） 誰と誰の約束か？ 契約 スケジュール 方針と規則
- 38. ドメインオブジェクトの見つけ方：まとめ • 語彙を増やす – キャッチフレーズ、ヘルプ、利用規約、… • 関連づける – 言葉と言葉の正しい組み合わせ方を学ぶ – 図よりも声に出してしゃべってみる • 初日からコードを書く（クラス名を考える） – とりあえずのひな型 ８クラス – 業務の関心事の発見パターン – メモ代わりに • src/main/java/domain/model を作って • ⌘N リターン 名前 リターン powered by Intellij IDEA
- 41. オブジェクト指向エクササイズ 1. １つのメソッドにインデントは１段階まで 2. else 句は使わない 3. すべての基本データ型をラップする 4. １行につきドットはひとつまで 5. 名前を省略しない 6. ５０行を超えるクラスを作らない 7. １つにクラスはインスタンス変数は２つまで 8. ファーストクラスコレクションを使う 9. getter / setter を使わない このガイドラインにそってコードを書けばモジュール性を向上できる
- 42. getter を使わない • getter がないということは、データを持つオブ ジェクトに仕事を依頼するしかない – get して自分で判断・加工・計算するのはNG • 基本データ型はすべてラップする • クラスは、最大２つのインスタンス変数しか持 ていない つまり • 基本データ型を１つか２つもった、５０行以内 のクラスに、業務ロジックを書く
- 43. 主役は値オブジェクト • 文字列・数値・日付を保持する • それらのデータを使った、判断・加工・計算を担 当する • 値オブジェクトの業務知識と振る舞いが豊かに なれば、業務ロジックの大半は値オブジェクトに 書かれるようになる • 名前（クラス名）がロジックの置き場所を導く – 省略しない – 同一のコード（式）の重複記述が激減する – わかりやすさ／変更の容易さの源泉
- 45. ドメイン駆動設計 しなやかな設計 1. 意図の明確なインタフェース 2. 副作用のない関数 3. 表明 4. 概念の輪郭 5. 独立したクラス 6. 閉じた操作 値オブジェクトの設計パターン 判断・加工・計算を依頼する メソッド名 言語の標準ライブラリのみ依存 業務の用語と値オブジェクトの名前を一致させる 完全コンストラクタ 不変オブジェクト 契約による設計 メソッドが返す型、受け取る型を 自分と同じ型にする BigDecimal, LocalDate, String は、ある程度、この条件を満たしている ただし、扱えるデータ範囲が広すぎ クラス名やメソッド名が漠然としていて意図が不明確
- 46. ドメインオブジェクトの作り方 • String, BigDecimal, LocalDate を一つか二つ持った 「値オブジェクト」を作る – クラス名で役割を明確に – 公開メソッドを少数に限定して意図を明確に – メソッド名で意図を明確に – 内部で保持するデータの範囲を限定して意図を明確に – 事前条件、事後条件、不変条件を明確に • null を渡さない、戻さない • ゼロ割り算をしない • 表明 and/or 例外のスロー
- 47. 値オブジェクトの例 String List<String> BigDecimal Integer … LocalDate Long 起算日 InitialDate 期限 DueDate 有効期間 ValidTerm 金額 Money 数量 Quantity 単位 Unit 品名 ProductName 備考 Remarks 摘要 Abstract 言語で用意された「型」 （汎用） 独自に定義した「型」 （目的特化） 47
- 48. 値オブジェクトの設計 • 完全コンストラクタ – すべてのインスタンス変数は、生成時に設定 • 不変 – setter を書かない（状態を変えない） – 値を変更する時は、別のオブジェクトを生成して返す – 不変による「安定」 • ロジックの置き場所 – インスタンス変数を使った、判断・加工・計算 – 何もしないで素のデータを返す getter はNG 48
- 49. 値オブジェクトが主役 • 業務の関心事の基本語彙の抽出手段 目的を限定した抽象データ型 – String, BigDecimal, LocalDateの値の範囲、文字 種、形式、計算範囲を業務に合わせて制限する – 用途を限定するとプログラムが安定する – コードの重複がなくなり、変更が楽になる • 関心事を豊かに表現する手段 – メソッドの戻す値の「型」 – メソッドの引数の「型」 49
- 50. コード例
- 51. public class UserIdentity { @NotBlank(message = "メールアドレスを入力してください") @Email(message = "メールアドレスが正しくありません。") String mail; public UserIdentity(@NotNull String mail) { this.mail = mail; } public String mail() { return mail; // ローカル部(@の前) だけ返すとか、さんづけとか… } @Override public String toString() { return mail; } } Mail に型づけされた文字情報 データ表現として、InternetAddress を使うのも選択肢
- 52. public class DateOfBirth { @NotNull(message = “誕生日を入力してください。”) LocalDate date ; // データ表現として 文字列ではなく、LocalDate型を使う String source; // 入力値の保持 boolean valid = true; // 入力値の有効性 public DateOfBirth(@NotNull String source) { this.source = source; try { LocalDate.parse(source); } catch ( DateTimeException exception) { valid = false; } } public Age age() { return new Age(this.date); // 年齢計算や表記は Age にまかせる } @AssertTrue(message = "日付が正しくありません。") public boolean isValid() { if(source.equals("")) return true; return valid; } @Override public String toString() { return source; } }
- 55. 形式的な隔離
- 56. 形式的な隔離
- 57. 形式的な隔離：お約束 クラス フィールド メソッド コントローラ PlanController @Conroller @RestController @ControllerAdvice @Autowired Service @RequestMapping @Validated アプリケーション PlanService @Service @Autowired Repository データソース PlanDatasource @Repository @Autowired Mapper データマッパー PlanMapper @Mapper @Param ドメイン Plan PlanRepository … @Valid @NotBlank @Size … @AssertTrue ドメイン以外は、お約束の名前とアノテーションでシンプルに記述 コードがごちゃごちゃしてきたら、ドメインロジックがドメイン層から流出している兆候
- 58. ドメインロジックをほんとうに隔離する • ドメインのロジックが書かれやすい個所 – ビューテンプレート – コントローラ – サービス – データソース – SQL文( where 句とか ) – 動的SQL文の組み立てロジック – テーブル • 値オブジェクトに置くべきちょっとしたロジックがころがって いないか、いつもきょろきょろする – コードがごちゃごちゃしてきたら、そこにロジックが見つかる – 値オブジェクトにロジックを移動する – 新しい値オブジェクトを作る
- 60. ドメインロジックをほんとうに隔離する • 外部のビュー構造から独立させる – 外部のビュー ： フラットな基本データ型の羅列 • テーブル • 画面( form のデータバインディング） • JSON – ドメインオブジェクト ： グラフ構造 • 構造変換 – グラフ ⇔ フラット – フレームワークを活用する ただし、フレームワークの都合は排除する ドメインの表現にこだわる 妥協しない
- 61. フレームワークの都合を排除する • O-R マッピング MyBatis SQL Mapper – ダイレクトフィールドアクセス ( getter/setter 不要) – 構造変換は、path 記法 ( plan.location.primary ) – null はマッピングされない • フォームバインディング Spring MVC DataBinder – ダイレクトフィールドアクセスに設定 (getter/setter を使わない) – 構造変換は、path 記法 – nullはバインドの対象外にする • O-JSON マッピング Jackson ObjectMapper – ダイレクトフィールドアクセスに設定 – 構造変換は、View クラスにやらせる • ドメインオブジェクトはどのような構造に変換されるか知らない
- 62. public class CustomObjectMapper { public ObjectMapper ofDirectFieldAccess() { ObjectMapper mapper = new ObjectMapper(); mapper.setVisibility(PropertyAccessor.FIELD,JsonAutoDetect.Visibility.NON_PRIVATE); mapper.setVisibility(PropertyAccessor.GETTER,JsonAutoDetect.Visibility.NONE); mapper.setVisibility(PropertyAccessor.SETTER,JsonAutoDetect.Visibility.NONE); return mapper; } } @ControllerAdvice public class BinderAdvice { @InitBinder public void initBinder(WebDataBinder binder) { binder.initDirectFieldAccess(); binder.registerCustomEditor(Object.class, new StringTrimmerEditor(true)); // ブランク文字列は、null とする // バインドの対象外となる } } ダイレクトフィールドアクセスの設定
- 63. ドメインオブジェクトの作り方：まとめ • 主役は値オブジェクト – データの保持（文字列、数値、日付） – データを使った、判断／加工／計算の置き場所 • オブジェクト指向エクササイズ ９つのルール – getter/setter を使わない – 名前は省略しない – ひとつのクラスにインスタンス変数は２つまで • ドメインを隔離する – 形式的な隔離 – ドメイン層以外へのロジックの記述に敏感になる – オブジェクトの世界／フラットな世界 • フレームワークを活用する • フレームワークや外部の都合を排除する
- 65. 育て方のシナリオ 1. 最初は器だけのクラスを作る – とりあえずのひな型８点セット – メモ代わりに作られたクラス名だけのクラス – コンストラクタと toString() だけの値オブジェクト ・・・ 2. 動かすために判断・加工・計算ロジックを書いていく – 理想：よく置き場所を考えて書く – 現実：てっとりばやく動かせる場所に書く 3. コードが増え、ごちゃごちゃしてくるので整理する – ドメインオブジェクトの持つデータを使って、判断・加工・計算してい るロジックを見つける（一行の式かもしれない） – そのロジック（計算・加工・判断）に名前をつける – 適切な場所にロジックを移動する（リファクタリング）
- 68. メソッドの抽出 • 基本中の基本 • ひとかたまりのロジック（判断・加工・計算）を 見つける – 改行 – コメント – ３行以上、改行がなかったら怪しい • かたまりに名前をつける（メソッドを抽出する） – 一行の式でも、抽出の対象（名前をつける対象） – このひと手間が、ロジックの移動を可能にする
- 69. クラスの抽出とメソッドの移動 • データに注目して別クラスを見つける – インスタンス変数が増えたら別クラスに • インスタンス変数は２つまで – いつもペアになっている変数や引数のグループ を見つけたらクラスに • prefix や、 suffix が同じ変数名は、グループ化の有力 候補 • そのクラスのデータを使う判断・加工・計算の ロジックを、そのクラスに移動する – メソッド名を考える – やりたいことや知りたいこと
- 70. 一時変数を値オブジェクトに • メソッド内の一時変数を持つ値オブジェクトを 作る • その値オブジェクトにロジックを移動する • もとのロジックを書き換える value = new ValueObject(一時変数） value.doSomething() • たった一行の式でも、こういう値オブジェクト にカプセル化すると、あちこちで利用可能に なる – コードの重複を減らす
- 71. 長いメソッドをオブジェクトに • ごちゃごちゃしたメソッドのリファクタリングの 定石 • メソッド名を名詞に変えたクラスを作る • そのクラスに、メソッドごとコピーする • 元のクラスのインスタンス変数、メソッドの引 数、一時変数をすべて、新しいクラスのインス タンス変数として宣言する • すべての変数がインスタンス変数なので、い かようにも、メソッドの分割ができる
- 75. 値オブジェクト String List<String> BigDecimal Integer … LocalDate Long 起算日 InitialDate 期限 DueDate 有効期間 ValidTerm 金額 Money 数量 Quantity 単位 Unit 品名 ProductName 備考 Remarks 摘要 Abstract 言語で用意された「型」 （汎用） 独自に定義した「型」 （目的特化） 75
- 77. 一覧オブジェクト （ファーストクラスコレクション） • ListやSetをラップしたドメインオブジェクト • Offers • MailBox • SkillSet • 「一覧」や「履歴」という関心事の表現 – 「一覧」は利用者の関心事が集中する場所 – 「一覧」の議論は、重要な関心事の発見の良い機会 • コレクションの操作は、コードがごちゃごちゃしや すく、変更の副作用が多い – クラスとして独立させ、そのクラスに閉じ込める 77 ９章 概念を掘り出す １０章 概念の輪郭
- 79. 区分オブジェクト • 振る舞いを持った Enum • 区分ごとのロジックを別クラスに記述 • Java言語使用に組み込まれた Strategy/Stateパターン 説明とコード例は、googleで 「場合わけの書き方あれこれ」で検索。 または「オブジェクト指向をきちんと使 いたいあなたへ」 場合ごとのビジネスルールの表現 79
- 80. 区分オブジェクトの効果 • 関心事の明示的なコード表現 • 複雑な if文記述の解消 – 区分ごとの分岐記述( if文 or switch文 )は、一箇所 になる – 場合によっては、まったく書かなくてよくなる • どこに何が書いてあるかわかりやすくなる – 区分ごとの業務ルールや知識のロジックの置き場所 をクラス単位で分離 • 区分の追加や削除をした時の、変更の副作用が 少ない 80 ９章 概念を掘り出す １０章 概念の輪郭
- 81. オブジェクトを育てる７つの視点
- 82. 振る舞いを豊かにするメソッド候補 視点 例 文字列で表現する show(), asText(), inThousand(), shortName() , fullName(), … 文字列から生成する parse(), of(), from(), … 同一性の判定 isSame(), equalsIgnoreCase(), … 比較・順序づけ compareTo(), before(), after(), … 計算 plus(), minus(), next(), previous(), with(), … 列挙 values(), contains(), valueOf(), … 上限・下限 max(), min(), within(), …. 元ネタは Haskell の組み込みの型クラス
- 84. しなやかな設計：６つのパターン 1. 意図の明確なインタフェース 2. 副作用のない関数 3. 表明 4. 概念の輪郭 5. 独立したクラス 6. 閉じた操作 モジュール性を改善するためのチェックリストとして使う
- 85. 予測可能に改善する 1. 意図を明確に – クラス名やメソッド名をみただけで、どんな判断・加工・計算を やってもらえるか、わかりやすいか？ 2. メソッドの副作用をなくす – query と command は同じメソッドにしない – クライアント側からとのお約束の例 • query で確認してから command 実行 • command を実行してから query で確認 3. 表明を具体的に – アノテーション – 例外のスロー宣言 – JavaDoc – assert 文 ( Java では使い物にならない） – テストコード ( 別モジュールになるのが難点）
- 86. モジュールの独立性を高める ４．概念の輪郭 – 業務の関心事とモジュールの単位を合わせる – どこに何が書いてあるかわかりやすく – 業務のニーズの変更とモジュールの変更の連続性を向上する ５．独立したクラス – 言語仕様と標準ライブラリだけに依存させると独立性が高くな る – 変更の影響が局所化しやすい – 再利用が容易 ６．閉じた操作 – メソッドの返す型、引数の型を、自身の型だけにする – 他のモジュールへの依存性が減る
- 87. ドメインオブジェクトの育て方：まとめ • ごちゃごちゃしてきたら整理する • 整理の基本はメソッドの抽出と移動 • 移動先の有力候補は、値オブジェクト、一覧 オブジェクト、区分オブジェクト • ７つの視点で振る舞いを豊かにする • ６つのパターンでモジュール性を改善する
- 88. 本日のまとめ 88
- 90. オブジェクト指向設計の 考え方とやり方 オブジェクト指向エクササイズ ９つのルール モジュール性 ５つの基準 抽象データ型 契約による設計 コードのいやな臭い その改善策１章 ドメインを学ぶ ２章 言葉を使う ３章 モデルと実装を結びつける ４章 ドメインを隔離する ５章 モデルを表現する部品 １０章 しなやかな設計 ４冊とも、想定読者はオブジェクト指向でコードを書く人 それぞれが関連している 今日は実践例として紹介してみたい
- 91. ドメインオブジェクト 設計の基本 ・モジュール性 凝集と結合 ・オブジェクト指向によるモジュール性 見つけ方 ・ドメインを学ぶ ・とりあえずのひな型 ・ドメインオブジェクトの発見パターン 作り方 ・主役は値オブジェクト ・ドメインを隔離する ・オブジェクト指向エクササイズ ９つのルール 育て方 ・リファクタリング いやな臭いと改善策 ・振る舞いを豊かにする７つの視点 ・しなやかな設計 ６つのパターン
- 92. ドメイン駆動設計への道 92
- 93. できない理由？ • 今のプロジェクトでは無理 • 今のチームでは無理 • 今の会社では無理 • 今の自分の力では無理 … 93
- 94. • どんな状況でも改善できる • どんなときでも「あなた」から改善を始められる • どんなときでも「今日」から改善を始められる ケント・ベックのメッセージ 94