ドメイン駆動設計本格入門

1. ドメイン駆動設計本格入門有限会社システム設計増田亨 PREMIUM #3 2019.3.22

2. はじめる前に • ブログを書くかもしれないという方へ 2019/3/22 ©有限会社システム設計 2

3. 全体の流れ 2019/3/22 ©有限会社システム設計 3 ドメイン駆動設計の考え方ドメイン駆動設計を理解する三つのキーワードエヴァンス本のススメレガシーに立ち向かうマイクロサービスとドメイン駆動設計

4. ドメイン駆動設計の考え方 ©有限会社システム設計 42019/3/22

5. 2019/3/22 ©有限会社システム設計 5 ドメイン駆動設計でなぜつくるのか「ソフトウエアの核心にある複雑さに立ち向かう」とはどういうことか？

6. ドメイン駆動設計でなぜつくるのか ©有限会社システム設計 62019/3/22

7. ソフトウェアの変更を楽で安全にするため ➢ 何年ものあいだ、成長と進化を続けるソフトウエア ➢ 新たな要求に対し柔軟性と拡張性をもってこたえるソフトウェア ➢ しなやかに設計された変更が容易なコードベース ➢ 豊富な機能を持った大きなシステムの段階的な成長出典：まえがき対照的な３つのプロジェクトエピローグ５つのプロジェクトのその後 2019/3/22 ©有限会社システム設計 7

8. すべてにプラスに作用する 2019/3/22 ©有限会社システム設計 8 変更が楽で安全ビジネスの要求開発スピード開発コスト運用コスト性能改善セキュリティ向上使いやすさ

9. すべてにマイナスに作用する 2019/3/22 ©有限会社システム設計 9 変更がやっかいで危険ビジネスの要求開発スピード開発コスト運用コスト性能改善セキュリティ向上使いやすさ

10. ドメイン駆動設計のやり方 ©有限会社システム設計 102019/3/22

11. 変更を楽で安全にするための 2019/3/22 ©有限会社システム設計 11 関心の分離の工夫モジュール構造の工夫

12. ソフトウェアの核心にある複雑さに立ち向かう ©有限会社システム設計 122019/3/22

13. ドメイン駆動設計を理解する三つのキーワード ©有限会社システム設計 132019/3/22

14. 2019/3/22 ©有限会社システム設計 14 ドメインロジック複雑さの根源ドメインモデル複雑さをモデルで整理オブジェクト指向モデルと実装の一致

15. 要点を絞り込む ©有限会社システム設計 152019/3/22

16. 2019/3/22 ©有限会社システム設計 16 ドメインロジック → ビジネスルールドメインモデル → 計算モデルオブジェクト指向 → 型指向のプログラミング

17. ビジネスルール ©有限会社システム設計 172019/3/22

18. ソフトウエアが複雑になる理由ビジネスルール金額、数量、期日、場所などの計算と判定ビジネスルールを適用する条件による分岐顧客区分、商品種別、有効期間、地域区分、金額区分、数量区分、取引種類、取引状態、支払い方法、支払いタイミング、割り増し条件、割引条件、キャンセル可能条件、… 2019/3/22 ©有限会社システム設計 18

19. 複雑さと戦う準備 ©有限会社システム設計 192019/3/22

20. ビジネスルールの記述を独立したモジュールに分離する 2019/3/22 ©有限会社システム設計 20

21. ビジネスルールの記述を独立させるプレゼンテーション層のモジュール群アプリケーション層のモジュール群データソース層のモジュール群ビジネスルールを記述したモジュール群利用する 2019/3/22 ©有限会社システム設計 21

22. ビジネスルールの記述を独立させる効果プレゼンテーション層のモジュール群がシンプルになるアプリケーション層のモジュール群がシンプルになるデータソース層のモジュール群がシンプルになる三つの層から区分判定などの条件分岐が激減する三つの層のモジュール群の設計がパターン化し安定する 2019/3/22 ©有限会社システム設計 22

23. ビジネスルールを記述するモジュール群に複雑さが集中する複雑なビジネスルールを整理しわかりやすく記述するための考え方とやり方 2019/3/22 ©有限会社システム設計 23

24. 従来のモジュール構造とビジネスルールトランザクションスクリプト機能（データ処理手続き）に分割したモジュール群ビジネスルールの記述、特に条件判定が、あちこちのモジュールに分散し、かつ、重複する変更がやっかいで危険 2019/3/22 ©有限会社システム設計 24

25. ビジネスルールの複雑さにどう立ち向かうか ©有限会社システム設計 252019/3/22

26. 計算モデル ©有限会社システム設計 262019/3/22

27. モデル • 複雑さに立ち向かうときの根底技法 • 全体をシンプルにとらえて説明する試み • 関心の分離 • 「抽象」というよりは「分離」 • 枝葉末節も、最終的には必要になるので安易に切り捨てない • 要点を特定することと、要点以外を無視することを混同しない • 焦点を合わせるが、周辺も見る（いったりきたりする） • （計算の）中核と周辺 • （計算の）主軸と補助軸 2019/3/22 ©有限会社システム設計 27

28. 計算モデル計算モデル • 計算式 • 判定式 • 判定結果による条件分岐データモデル • 計算（プログラム）の関心事から独立したデータの記録と参照のモデル • ビジネスアプリケーションを実現するために必須 • しかし、ソフトウェアの複雑さに立ち向かう主軸ではない 2019/3/22 ©有限会社システム設計 28

29. ビジネスルール → 計算モデル ©有限会社システム設計 292019/3/22

30. ビジネスルールのモデリング Fact 事実の表現ビジネスの状況の記録や通知に使う値の種類・数値、日付、場所、識別番号、名称、… Rule Factを使った計算や判定のロジック計算式同一性の判定式大小の比較式 Goal 知りたいこと計算結果や判定結果を表現する値の種類・合計金額、予定日、残数、… ・出荷可否、受付可否、割引種類、… 2019/3/22 ©有限会社システム設計 30

31. ビジネスルールのモデリング • データモデル → 外周の関心事 • 計算に必要な元データの記録と参照 • 計算結果の記録 • 計算モデル → 中核の関心事 • ビジネスルールの計算ロジック判定ロジックそのもの • メモリ上で完結する • 計算と入出力の分離 • 計算の準備としての入力 • 計算の後処理として出力 2019/3/22 ©有限会社システム設計 31

32. ビジネスルールの記述が中核の関心事プレゼンテーション層のモジュール群アプリケーション層のモジュール群データソース層のモジュール群ビジネスルールを記述したモジュール群利用する 2019/3/22 ©有限会社システム設計 32

33. 計算モデルをどう整理して記述するか ©有限会社システム設計 332019/3/22

34. 型指向のプログラミング ©有限会社システム設計 342019/3/22

35. 型指向のプログラミングビジネスルール（計算／判定）の記述をモジュール化する基本値の種類（＝型）ごとにクラス(モジュール）定義する例：数値を扱う BigDecimal型, 日付を扱う LocalDate型ただし、個々のビジネスルールを記述するには汎用的すぎる 2019/3/22 ©有限会社システム設計 35

36. 型指向のプログラミングビジネスルールに登場する値を分類する値の種類(=型)ごとに、独自のクラスを定義する値の種類ごとに有効な値の範囲を定義する値の種類ごとに必要な計算・判定のロジックを記述する 2019/3/22 ©有限会社システム設計 36

37. ビジネスルールを型指向のプログラミングで記述する 2019/3/22 ©有限会社システム設計 37

38. ビジネスルールを記述する3要素 Fact 事実の表現ビジネスの状況の記録や通知に使う型・数値、日付、場所、識別番号、名称、… Rule Factを使った計算や判定のロジック計算式同一性の判定式大小の比較式 Goal 知りたいこと計算結果や判定結果を表現する型・合計金額、予定日、残数、… ・出荷可否、受付可否、割引種類、… 2019/3/22 ©有限会社システム設計 38

39. Fact-Rule-Goalで記述する３つの設計パターン値オブジェクトロジックを持ったenum コレクションのカプセル化 2019/3/22 ©有限会社システム設計 39

40. 値オブジェクト 2019/3/22 ©有限会社システム設計 40

41. 値オブジェクトとは？ • Fact の表現手段 • 数値、時間、場所、識別番号、識別名称、… • ビジネスとして適切な値の範囲を定義する • Rule （計算ロジックや判定ロジック）の置き場所 • Factを使う計算や判定をメソッドとして記述する • Factと持つオブジェクトに、関連するロジックを集める • Goal 知りたいこと（計算結果、判定結果）の表現手段 • 知りたいことを表現した型（値の種類）を設計する • メソッドの返す型として使う 2019/3/22 ©有限会社システム設計 41

42. 値オブジェクトのカタログ単一の値範囲型（from-to）範囲型のコレクション数値金額型 Amount, Money 金額範囲 x円以上 y円未満金額範囲のコレクション価格帯数量型 Quantity, NumberOfXxx 数量範囲 m人以上 n人以下数量範囲のコレクション数量別割引率時間日付型 DueDate, XxxDate 期間開始日 - 終了日期間のコレクションシーズン時刻型 HourTime, XxxTime 時間開始時刻 – 終了時刻時間のコレクション時間帯空間地点型 Point 接続 Path:出発点 – 到達点接続のコレクション Route [Path,…] - 地域型 Area, Zone 地域のコレクション階層、隣接関係、… 2019/3/22 ©有限会社システム設計 42

43. 値オブジェクトの効果 • 値オブジェクト＝ビジネスに特化した値の種類を明示的に表現 • 動かすだけなら、プログラミング言語が提供する汎用的な型だけでよい • プログラムの表現が、ビジネスルールの記述そのものになる • 値の種類単位で、ビジネスロジックの記述が一か所にまとまる • プログラムのあちこちにビジネスルールの記述が重複しない • ビジネスルールが変わったときのソフトウェアの変更が楽で安全 2019/3/22 ©有限会社システム設計 43

44. 値オブジェクトを設計する計算の意図を、メソッド名とメソッドの返す型で説明する 2019/3/22 ©有限会社システム設計 44

45. 計算の種類説明、メソッド例結果の型等値判定 isEqual( other ) , notEqual( other ) boolean / enum 大小判定 greaterThan( other ), lessThan( other ), … boolean / enum 加算・減算同じ型同士の計算同じ型乗算同じ型同士の乗算は意味がないことが多い別の数値型除算同じ型の除算と、異なる型の除算では、意味が異なる別の数値型境界 Max, Min の存在同じ型（の固定値）列挙 prev(), next() が可能な集合（循環が可/不可）同じ型文字列表現値の標準的な文字列表現 toString() 文字列文字列からの生成標準的な文字列表現からのオブジェクト生成 parse() 同じ型計算の候補（単一値） 2019/3/22 ©有限会社システム設計 45

46. 計算の種類説明、メソッド例結果の型等値判定 isEqual( other ) , notEqual( other ) boolean / enum 大小判定 greaterThan( other ), lessThan( other ), … boolean / enum 範囲に含まれる contains( element ), encloses( other ) boolean / enum 範囲が重複する isOverlapped(other) boolean / enum 厳密に隣接する isConnectedTo(other) boolean / enum 境界の値 Max, Min , 要素の型範囲演算 intersect(other), minus(other), add(other) 範囲型文字列表現標準的な文字列表現 toString(), show(), describe() 文字列計算の候補（範囲型 from-to） 2019/3/22 ©有限会社システム設計 46

47. 計算の種類（メソッド）の設計原則 • ある値について、ビジネスルールに必要な計算は、限定的 • 金額と金額の足し算はある • 金額と金額の掛け算はない • ビジネスルールの値の範囲は、限定的 • 境界値がある • １以上９９まで • 現在日以降９０日以内 • 計算の意図を、メソッド名、メソッドの渡す引数の型、メソッドの返す型で説明する 2019/3/22 ©有限会社システム設計 47

48. 値オブジェクトを使って変更を安全にする契約による設計 2019/3/22 ©有限会社システム設計 48

49. 契約による設計変更を楽で安全にするための設計技法 assert による表明型による表明防御的な検査コードを書かない事前条件（クラスを使う側の責任：引数の型）事後条件（計算を提供するクラスの責任：返り値の型）暗黙のビジネスルールの明文化につながる値の範囲と計算の種類を限定 → 動作が安定する 2019/3/22 ©有限会社システム設計 49

50. enumを使った区分ごとのロジックの整理 2019/3/22 ©有限会社システム設計 50

51. 区分ごとのビジネスルールを扱う区分ごとの条件分岐が複雑さの大きな原因 enumは区分ごとのロジックを整理する強力な手段 enumを使うと区分体系の問題の発見と改善が進む 2019/3/22 ©有限会社システム設計 51

52. 区分を列挙しただけのenumを作る区分ごとの定数をenumのフィールド変数に移動区分ごとの計算や判定のロジックをenumのメソッドに移動コードがゆがむ（フィールド変数やメソッドの一貫性が崩れる）区分のリファクタリング（区分の分解、再定義）ビジネスルール記述のわかりやすさにブレークスルーが起きる 2019/3/22 ©有限会社システム設計 52

53. コレクションのカプセル化 2019/3/22 ©有限会社システム設計 53

54. コレクション操作の問題と改善問題あちこちにコレクションを操作する類似の記述が分散バグが紛れ込みやすい（計算の不整合が起きやすい）コレクション操作の手続きは、ビジネスの関心事ではない改善策目的別のコレクション型を独自につくるコレクション操作のロジックをそのクラスに集めるコレクション操作の詳細を隠蔽する 2019/3/22 ©有限会社システム設計 54

55. コレクションのカプセル化の効果コレクション操作がちらばっていたコードのぐちゃぐちゃ感が消えるコレクションに必要な計算を集めると、リファクタリングがやりやすいコレクション操作の整合性と一貫性が向上するコレクション操作という技術手段が隠蔽されクラス名、メソッド名、メソッドの返す型でビジネスの関心事が前面に登場する 2019/3/22 ©有限会社システム設計 55

56. 計算の種類説明、メソッド例結果の型サイズ count() int 要素の検査 contains(要素), isEmpty(), notEmpty() boolean / enum 部分集合 select(条件), reject(条件), コレクション集約演算 sum(), min(), max(), average(), … 集約結果の型集合演算 insersect(other), minus(other), add(other) コレクション変換 unique(), sort(), groupBy() コレクション要素の取り出し first(), last(), at(index) 要素の型要素の追加 add(), addAll(), append(), insertAt(), … void 文字列表現 show(), describe() 文字列, 文字列[ ] 計算の候補（コレクション） 2019/3/22 ©有限会社システム設計 56

57. ドメイン駆動設計を理解する三つのキーワード ©有限会社システム設計 572019/3/22

59. エヴァンス本のススメ 2019/3/22 ©有限会社システム設計 59

60. エリック・エヴァンスのドメイン駆動設計 2019/3/22 ©有限会社システム設計 60

61. 登場するパターン 2019/3/22 ©有限会社システム設計 61 基本要素エンティティ値オブジェクトドメインサービスモジュールオブジェクトのライフサイクル集約（アグリゲート）リポジトリファクトリユビキタス言語モデル駆動設計実践的モデラーしなやかな設計意図の明白なインタフェース副作用のない関数表明概念の輪郭独立したクラス閉じた操作レイヤードアーキテクチャスマートUI コンテキスト境界継続的な統合コンテキストマップ共有カーネル顧客・供給者順応者腐敗防止層別々の道公開ホストサービス公表された言語コアドメイン汎用的なサブドメイン凝集されたメカニズムドメインビジョン声明文コアのハイライトコアの隔離コアの抽象化進化する秩序システムのメタファ責務のレイヤ知識レベル・運用レベル

62. パターンについて • ひとつひとつのパターンだけ取り上げて理解しても役に立たない • よく登場するパターン名がドメイン駆動設計の本質ではない • パターンの背景にある動機を理解する • パターンとパターンの関係を理解する • そのためには、パターンの拾い読みではなく、本の構成と全体の流れを理解したほうが良い 2019/3/22 ©有限会社システム設計 62

63. よく登場するパターンへの注釈エンティティビジネスルールや計算モデルとして主要な関心事ではないどちらかといえば入出力（記録と参照）の関心事値オブジェクトビジネスルールの整理と実装の主役計算モデルの構成要素として、別格の重要度ドメインサービス型指向のプログラミングの道具ではないメソッドの引数をインスタンス変数に持つオブジェクトの設計を試みる集約（アグリゲート）計算ロジックの集約データの集約ではない維持するのは、データベースの整合性ではなく、計算の整合性と一貫性リポジトリ計算の準備と計算結果の記録の仕組み入出力の関心事であり、計算モデルの一部ではない 2019/3/22 ©有限会社システム設計 63

64. よく登場するパターンへの注釈ユビキタス言語目的ではない共通言語どこにでも、いつでも登場する言葉ビジネスをどこまで理解し、意識してコードを書いているかの評価軸コードや技術者同士の会話で、どこでも、いつでも登場しているか？境界づけられたコンテキスト目的ではないコミュニケーションや共通理解の現状を把握する手段一つのチームに複数のコンテキストが存在するリスクへの警鐘（継続的な統合:CI）ビルドとテストの自動化が本質ではない(ビルドOK,テストOKでは不十分) チーム内で、ビジネスルール理解と計算モデル表現を整合させるそのためには頻繁な会話が必要（特にちょっとした違和感の確認）コンテキストマップ計算モデルのマッピングデータ入出力のマッピングではない同じ計算モデルの通用範囲値の種類の名前が登場するかしないか同じ名前の値の種類は、内容が同じか（値の範囲、計算の種類） 2019/3/22 ©有限会社システム設計 64

65. エヴァンス本の要点を確認する ©有限会社システム設計 652019/3/22

66. ドメイン駆動設計でなぜつくるのか ©有限会社システム設計 662019/3/22

67. ソフトウェアの変更を楽で安全にするため ➢ 何年ものあいだ、成長と進化を続けるソフトウエア ➢ 新たな要求に対し柔軟性と拡張性をもってこたえるソフトウェア ➢ しなやかに設計された変更が容易なコードベース ➢ 豊富な機能を持った大きなシステムの段階的な成長出典：まえがき対照的な３つのプロジェクトエピローグ５つのプロジェクトのその後 2019/3/22 ©有限会社システム設計 67

68. 2019/3/22 ©有限会社システム設計 68 ドメインロジック複雑さの根源ドメインモデル複雑さをモデルで整理オブジェクト指向モデルと実装の一致

69. 要点を絞り込んで理解する ©有限会社システム設計 692019/3/22

70. 2019/3/22 ©有限会社システム設計 70 ドメインロジック → ビジネスルールドメインモデル → 計算モデルオブジェクト指向 → 型指向のプログラミングこのように意味を限定して読んでみると、ずいぶんわかりやすくなる

71. エヴァンス本の全体構成を理解する ©有限会社システム設計 712019/3/22

72. 全体の構成 2019/3/22 ©有限会社システム設計 72 第１部ドメインモデルを機能させる第２部モデル駆動設計の構成要素第３部深い洞察に向かうリファクタリング第４部戦略的設計１章～３章４章～７章８章～１３章１４章～１７章概論と基本事項ここだけでは役に立たない役に立つモデルを手に入れるための実用的な設計技法大規模に適用する長期的に取り組むための技法

73. エヴァンス本の中核 ©有限会社システム設計 732019/3/22

74. 第３部：役に立つモデルの実用的な設計技法 2019/3/22 ©有限会社システム設計 74 ９章暗黙的な概念を明示的にする１０章しなやかな設計ビジネスルールがコードで明示できてないことの検知「制約」や「ルール」をクラスやメソッドで表現する実験ぎこちなくても、とにかくコードにしてみる明示的になった素材を改善する設計技法意図の明白なインタフェース副作用のない関数表明概念の輪郭独立したクラス閉じた操作表現を改善するビジネスを理解する

75. 第４部：大規模に長期的に取り組む 2019/3/22 ©有限会社システム設計 75 １４章モデルの整合性を維持する１５章蒸留１６章大規模な構造大規模・長期的に取り組むための準備境界づけられたコンテキスト継続的な統合コンテキストマップビジネスルールの複雑さの整理とモジュール構造の改善コアドメイン汎用的なサブドメイン凝集されたメカニズムドメインビジョン声明文コアのハイライトコアの隔離コアの抽象化全体の関係を共通理解にするモデル間の関係の整理と改善責務のレイヤ（能力・運用・約束・ポリシー）知識レベルと運用レベル

76. 複雑なビジネスルールに立ち向かう技法 ©有限会社システム設計 762019/3/22

77. ビジネスルールの分析設計従来のアプローチ 2019/3/22 ©有限会社システム設計 77

78. 従来のアプローチ • プロセスモデリング • 機能分割 • トランザクションスクリプト • データモデリング • ERモデリング • CRUD分析 • データベースアクセスのスクリプティング • ビジネスルールの発見と整理が、主軸ではない • その結果、ビジネスルールがあちこちにちらばり重複する 2019/3/22 ©有限会社システム設計 78

79. ビジネスルールの分析設計ドメイン駆動設計のアプローチ 2019/3/22 ©有限会社システム設計 79

81. ビジネスルールを記述する3要素 Fact 事実の表現ビジネスの状況の記録や通知に使う型・数値、日付、場所、識別番号、名称、… Rule Factを使った計算や判定のロジック計算式同一性の判定式大小の比較式 Goal 知りたいこと計算結果や判定結果を表現する型 2019/3/22 ©有限会社システム設計 81

82. Fact-Rule-Goalで記述する３つの基本パターン値オブジェクトロジックを持ったenum コレクションのカプセル化 2019/3/22 ©有限会社システム設計 82

83. ビジネスルールの発見と整理の枠組み 2019/3/22 ©有限会社システム設計 83

84. 責務のレイヤ（能力・運用・約束・ポリシー） 2019/3/22 ©有限会社システム設計 84

85. 責務のレイヤの例ポリシー事業運営の決め事価格、割引、優遇、拒絶オーバーブッキングキャンセル約束顧客との契約取引先との契約見積予約注文運用ビジネス活動の実態（イベント）出荷、売り上げ請求、回収能力ビジネスの現実（リソース）在庫出荷能力処理能力 2019/3/22 ©有限会社システム設計 85

86. ビジネスルールの３つの源泉価値提供の約束と支払いの約束ビジネス活動の連鎖／約束の連鎖競争優位の獲得策／競争劣位の防止策契約バリューチェーン事業運営ポリシー 2019/3/22 ©有限会社システム設計 86

87. 約束何を（区分）どのくらい(数量) いつ(日時）いくらで（金額）誰に（区分） 2019/3/22 ©有限会社システム設計 87

88. 能力：約束してよいこと／約束できないこと出荷可能な在庫配送能力キャパシティ（空席、空きスペース、…）アベイラビリティ（人、空間、モノ、…) 2019/3/22 ©有限会社システム設計 88

89. 運用：約束の履行の監視と促進の決め事いつ何が起きるべきか（イベント区分、状態区分）起きたことの検知起きなかったことの検知起きた場合のアクション起きなかった場合のアクション 2019/3/22 ©有限会社システム設計 89

90. ポリシー • 価格、割引 • 特典、優遇 • 提供ポリシー（時間、場所、相手、許容量、…) • オーバーブッキング • 与信 • キャンセル 2019/3/22 ©有限会社システム設計 90

91. 約束違反の扱いの決め事約束のキャンセル（可否の判断、可能な場合の補償）価値を提供できなかった時のルール（返品、返金、…）対価の支払いができなかった時のルール（ペナルティ、…） 2019/3/22 ©有限会社システム設計 91

92. エヴァンス本の構成 2019/3/22 ©有限会社システム設計 92 第１部ドメインモデルを機能させる第２部モデル駆動設計の構成要素第３部深い洞察に向かうリファクタリング第４部戦略的設計１章～３章４章～７章８章～１３章１４章～１７章概論と基本事項ここだけでは役に立たない役に立つモデルを手に入れるための実用的な設計技法大規模に適用する長期的に取り組むための技法

93. ドメイン駆動設計の考え方でレガシーに立ち向かう 2019/3/22 ©有限会社システム設計 93

95. ビジネスルールを記述する3要素 Fact 事実の表現ビジネスの状況の記録や通知に使う型・数値、日付、場所、識別番号、名称、… Rule Factを使った計算や判定のロジック計算式同一性の判定式大小の比較式 Goal 知りたいこと計算結果や判定結果を表現する型 2019/3/22 ©有限会社システム設計 95

97. レガシーへの立ち向かい方：心の準備 • ありがちな設計 • トランザクションスクリプト（機能単位のモジュール） • バッチ処理 • テーブルは更新可能なデータファイル • ありがちな状況 • 設計や分析の資料はない／あっても古くてコードと一致していない • 命名規約は、番号重視 and/or 省略重視 ( KBN01 ) • 使われていないロジック、データ、区分が混在 • 手がかり • 実際に業務が回っている（実データがある） • 画面、出力帳票、データ交換用のファイル 2019/3/22 ©有限会社システム設計 97

98. レガシーへの立ち向かい方：手がかり • 実データ、実画面、実帳票、実ファイル • 実際に使われているデータ（事実の記録）が最大の手がかり • プログラムの意図は、コードからは読み取りにくい • そういう設計のスタイルだから • コードは意図の表現ではなく、データ処理の手続きの実現 • 目のつけどころ • 区分値ビジネスルールの複雑さの根源 • 導出項目ビジネスルールの計算・判定の結果 2019/3/22 ©有限会社システム設計 98

99. 区分値の調査と分析 • コード内のif文やswitch文と格闘する前に、区分体系を徹底的に調査する • データベースの区分カラム • GROUP BY 句で、実際のデータ内容の確認 • 区分によって、使うカラム／使わないカラム、意味の異なるカラムの特定 • 画面の区分表示、区分選択ボックス • データベースの区分カラムとの対応 • 業務的な使い方の確認 2019/3/22 ©有限会社システム設計 99

100. 導出項目の調査と分析 • 導出項目の特定 • ビジネスルールを適用した計算結果 • 金額、数量、期日、場所、区分 • 画面の表示項目 • データベースに記録された導出結果 • 導出ルールの調査 • 業務マニュアル／利用ガイド／料金表 … • ソースコード • ヒアリング（ありえないデータ、ありえない結果を判断できる能力を持つ人） 2019/3/22 ©有限会社システム設計 100

101. あるべき姿の中核を見極める • 導出（計算・判定）に焦点を合わせる • 単なる記録と参照は、いったんスコープ外にする • データベースは、計算・判定で使う項目に焦点を合わせる • 画面項目も、計算・判定で使う項目／導出結果に焦点を合わせる • ソースコード中の、計算式と判定式に焦点を合わせる • 単なるデータの記録と参照は、ばっさりスコープからはずす 2019/3/22 ©有限会社システム設計 101

102. あるべき姿の中核を生み出す • データベース • 導出の元になるデータと、導出結果だけに絞り込んだデータベースを用意する • FACTを正しく記録するためのテーブル群を新規に設計 • イミュータブルデータモデル • データベース制約を徹底する • 特に NOT NULL 制約 • 現行のデータベースから必要データを複製する仕組みづくり • 導出ロジックのプログラミングと検証 • FACT駆動で作成した新データベースから、必要な計算・判定ができるプログラムを開発する • 計算結果・判定結果を、既存データベースの該当カラムと突き合わせる 2019/3/22 ©有限会社システム設計 102

103. 複雑さの核心に切り込む • 既存の区分体系 • 未使用の区分 • 今となっては意図が不明な区分 • 複数の区分軸の混在 • 区分体系の整理 • 未使用を使わない • 意図不明もいったん使わない • 明らかな例外を、事前処理で除外する • 残った区分を論理的に分解する • ２軸か３軸の組み合わせになっていることが多い • すべての組み合わせが網羅されていないことが多い（その理由を分析する） 2019/3/22 ©有限会社システム設計 103

104. アプリケーションとして組み立てる • 中核は手に入った • FACTを記録したテーブル群（と実データ） • FACTを使った導出プログラム（計算モデル） • 計算サービス、判定サービス • 中核を使って • 画面や外部インタフェース • 作り直す • 既存の画面処理プログラムや、外部インタフェースプログラムから呼び出す • 記録して参照するだけのデータ群 • 中核の外周に追加する • 既存の処理にまかせる 2019/3/22 ©有限会社システム設計 104

106. マイクロサービスアーキテクチャひとつのアプリケーションを複数のサービスで構築する開発の独立性 • サービスごとに開発活動が独立 • サービスごとに修正・拡張が独立 • サービスごとに設計改善が独立配置と運用の独立性 • サービスごとに運用が独立 • ただし、高可用性が要求される • サービス単位での自動スケーリング 2019/3/22 ©有限会社システム設計 106

108. 2019/3/22 ©有限会社システム設計 108 分割の軸説明予想されるアンチパターンビジネス能力ビジネスアーキテクチャに合わせる部門・業務・職務（３段階の機能分割）大きなきれいな絵と入り組んだ現実のシステム構造ドメインモデルビジネスルール単位で分割・価格、割引、特典、… ・在庫引き当て、予約、キャンセル、… ルールの依存性の整理の失敗区分設計の失敗アクション指向アクション単位（イベント単位）に分割引き合い、見積、在庫確認、受注、出荷指示、売上計上、請求、… 手続き的なモジュール構造ロジックがあちこちに重複リソース指向リソース単位に分割リソース管理番号（ Entity, URI ) FatなEntity/テーブル巨大な中央データベース or データの重複と不整合

109. 分割の方針４つの軸の組み合わせになる課題 • 主軸の選択 • 補助軸の組み合わせの優先順位の選択 • 大規模な取り組みの一貫性と整合性の維持 • 長期的な取り組みの一貫性と整合性の維持 • 「最初から正しい分割はできない」 • 継続的な「分割の見直し」の現実性 2019/3/22 ©有限会社システム設計 109

111. ドメイン駆動設計 • マイクロサービスへの分割を目的とはしていない • 良い設計（適切な関心の分離と変更容易なモジュール構造）を目指していると • シンプルなサービスの分割に進化していく • シンプルなデータベース構造に進化していく • その結果、マイクロサービス化をやりやすくなる • 配置・運用を実際にマイクロサービス化するかは、要件しだい • マイクロサービス化のトレードオフを検討する • 不必要な複雑さを持ち込まない 2019/3/22 ©有限会社システム設計 111

112. モノリスからマイクロサービスへの段階的移行 • ドメイン駆動設計で関心の分離とモジュール構造の改善を積重ねる • 最初はシステム全体のあちこちが変更対象になる • この段階でのマイクロサービス化は失敗への道 • ある程度、開発と設計改善が進むと • アプリケーション層のクラス／メソッドが安定する • データベース設計が安定する • この段階になってから、（必要なら）マイクロサービス化を検討する 2019/3/22 ©有限会社システム設計 112

116. アプリケーション層の複雑さビジネスルールの記述を、ビジネスロジック層に移動する理論的にはアプリケーション層はとてもシンプルになる現実はアプリケーション層に複雑なロジックが残りやすいアプリケーション層の複雑さの分析と整理 (VETRO, Saga) 2019/3/22 ©有限会社システム設計 116

118. VETRO 分析とは？ビジネストランザクションをビジネスメッセージの処理としてとらえるメッセージ処理を5種類のアクション(VETRO)に分解してみるアクションごとに、どのルールをどのタイミングで適用するか検討する 2019/3/22 ©有限会社システム設計 118

119. VETRO Validation 妥当性検証 Enrich 情報付加 Translate 情報導出 Routing 分岐判定 Operation 通知/記録ビジネスメッセージサービスを実行するステップの分解それぞれのステップで、ビジネスルールの計算・判定をする可能性ステップが複雑になる場合は、サービス単位を分けることを検討する 2019/3/22 ©有限会社システム設計 119

120. VETRO ビジネスメッセージ Event 通知、Document送付 Query 問い合わせ、Command 指示 Validation 妥当性検証メッセージ内容の妥当性を検証するデータ形式、必須属性、値範囲、… Enrich 情報付加メッセージに含まれたIDなどから、関連する情報を収集するルール（ex. 顧客ID->顧客購買履歴) Translate 情報導出付加された情報を元に、新たな情報を導出するルール（ex. 購買履歴 → 顧客ランク ) Routing 分岐判定導出された情報を元に、適切なオペレーションに分岐させるルール ( ex. 顧客ランクごとの対応 ) Operation 通知/記録通知ルール：誰に何を通知すべきか？記録ルール：どこに何を記録すべき？ 2019/3/22 ©有限会社システム設計 120

122. Sagaとは？ ③が不成立だった場合、①と②にキャンセル処理を実行するという、さまざまな状況とその対応方法(undo)の物語を用意する ①②③を、独立して、順不同で実行する（それぞれの物語）三つともOKであれば、それで完了（Happy Goal) 独立したトランザクション A 独立したトランザクション B 独立したトランザクション C ビジネスメッセージコーディネータひとつの大きなトランザクション → 独立した複数の小さなトランザクションに分割 2019/3/22 ©有限会社システム設計 122

123. Sagaとは？独立したトランザクションのコミット • 個々のトランザクションは独立して確定する（できる）ビジネス的な undo の仕組み • どこかで不都合な状況が発生した場合、キャンセル処理など適切なカウンタートランザクションを実行する仕組みを用意するビジネスレベルでの代替アクションの分析と実装 • 自動的なundo以外に、人間系の代替プロセスや取消プロセスの実行に引き継ぐパターンも選択肢 • その場合の支援機能を用意する 2019/3/22 ©有限会社システム設計 123

125. マイクロサービスに発展可能なデータベース設計 • 事実の記録を徹底する（イベントソーシング） • テーブル単位（カラム構成）を計算の関心事に従属させる • 事実と参照を分ける（テーブル→スキーマ→データベース） • 事実と導出結果を分ける（テーブル→スキーマ→データベース） 2019/3/22 ©有限会社システム設計 125

126. 事実の記録：データベース設計の基本事実の記録の原則 • NULL という事実はない • NOT NULL 制約にできないカラムは事実の記録として欠陥 • オプショナルな項目は、別テーブルにする • 発生時点の異なる事実は、別テーブルにする • 有効な値の範囲を定義する(型指向の設計）外部キー制約には２つの意味がある • 事実の前後関係（重要） • 同じ時点の事実を別テーブルにしている関係（別事実に分解すべき可能性） 2019/3/22 ©有限会社システム設計 126

127. テーブルの分割関数従属性 • キーに従属するデータは同じテーブルに • この原則だけだと、テーブルが肥大化しがち発生時点で分解 • 事実の発生した時点が異なれば別テーブルにわける計算従属性 • 計算単位ごとに、計算に必要な事実を別テーブルに分ける ○ 商品番号に従属し、かつ、価格計算に関係にあるカラムだけのテーブル × 価格以外に、カタログ情報や在庫情報を持つ肥大化した商品マスター 2019/3/22 ©有限会社システム設計 127

128. 分離・独立を段階的に発展させるテーブル → スキーマ → データベースいきなりデータベース単位の分割を検討しない 1. 小さなテーブル単位に役割を分け、利用特性を明確にする 2. 同じ特性のテーブルをスキーマでグルーピング 3. スキーマ単位の参照権限・更新権限を徹底する 4. 独立性の高いスキーマを別データベースへの切り出しを検討する 2019/3/22 ©有限会社システム設計 128

129. 記録と参照、事実と導出結果の分離 2019/3/22 ©有限会社システム設計 129 事実の記録事実の複製導出結果（残高,状態,集計）イミュータブルイミュータブルミュータブル INSERT SELECT SELECT 永続化を保証する事実から再生可能事実から再生可能複製 delete/ insert created_at updated_at

130. ドメイン駆動設計マイクロサービスへの分割を目的とはしていない良い設計（適切な関心の分離と変更容易なモジュール構造）を目指す • シンプルなサービスへの分割に進化していく • シンプルなデータベース構造に進化していく • その結果、マイクロサービス化をやりやすくなる実際に配置・運用をマイクロサービスに分割するかは、要件しだい • マイクロサービス化のトレードオフを検討する • 不必要な複雑さを持ち込まない 2019/3/22 ©有限会社システム設計 130

136. ビジネスルールのモデリング Fact 事実の表現ビジネスの状況の記録や通知に使う値の種類・数値、日付、場所、識別番号、名称、… Rule Factを使った計算や判定のロジック計算式同一性の判定式大小の比較式 Goal 知りたいこと計算結果や判定結果を表現する値の種類・合計金額、予定日、残数、… ・出荷可否、受付可否、割引種類、… 2019/3/22 ©有限会社システム設計 136

139. エヴァンス本の構成 2019/3/22 ©有限会社システム設計 139 第１部ドメインモデルを機能させる第２部モデル駆動設計の構成要素第３部深い洞察に向かうリファクタリング第４部戦略的設計１章～３章４章～７章８章～１３章１４章～１７章概論と基本事項ここだけでは役に立たない役に立つモデルを手に入れるための実用的な設計技法大規模に適用する長期的に取り組むための技法

ドメイン駆動設計本格入門

ドメイン駆動設計本格入門

Recommended

More Related Content

What's hot

What's hot(20)

Similar to ドメイン駆動設計本格入門

Similar to ドメイン駆動設計本格入門(20)

More from 増田亨

More from 増田亨(20)