More Related Content Similar to 「ドメイン駆動設計」の複雑さに立ち向かう (20) 「ドメイン駆動設計」の複雑さに立ち向かう14. LocalDate
クラス
日付を汎用的に扱う手段
Java APIのレイヤ
int year
short month
short day
LocalDateの内部
Java言語仕様のレイヤ
if( day > 31 ) …
DateOfBirth
クラス
「誕生日」に用途を限定した独自定義クラス
「ドメイン層」の一級市民(ドメインオブジェクト)
人間の発想
コンピュータの
仕組み
抽象データ型/段階的な抽象化
人間の発想に近づける
Boolean 今月が誕生月()
Days 誕生日まであと何日()
plusDays()
plusMonths()
39. 第1章 まとめ
• 「モデル」の成長する様子
• 知識のないところから出発する
• 語彙を増やす
• 正しい言い方(正しい意味)を覚える
• コードでも表現してみる
• 本質的な関心事を探す
• 継続的に学ぶ
• 知識をかみ砕いた成果が「ドメインモデル」
– 利用する人たちの「活動」と「関心事」の本質を「簡潔」
に表現した言葉・図・コード
42. 声に出してモデリングする
• 良いモデルを見つける実践的な方法
– 語尾まで明瞭に語ってみる
– しゃべりにくい
– 要点が聞き取れない
• 復唱ゲーム
– 同じことを、別の人/別のタイミングで「同じ」に語れるか
– 同じ言葉、同じ言い回しにならない
• 他の表現との不一致に敏感に
– コード、図、コミットログ、チャット、メールなど書かれた言葉
– 笑っちゃうくらう一致していない(意味、重要度)
• チームのドメインの理解が進み、重要な関心事がはっきりし
てくると、よどみなく同じ言い回しがでてくるようになる
59. ドメインの「隔離」
• 表面的な分離は簡単
• 現実
– コントローラ層やページ記述にしみだした業務知識
• if(未承認なら) setDisable()
– 複雑なSQL文にまぎれこんだ業務知識
• NOT EXIST xxx OR customer.type = 1
• 業務知識のまぎれこみに敏感になる
– アンチパターンを覚える
– 継続的にリファクタリングする
• 画面駆動の開発はコントロールや画面でドメイン知識を記述するア
ンチパターンが横行する
• データベースのフラグと区分もアンチパターンの宝庫
75. ドメイン層の「サービス」 危険!
• 「手続き」にドメインの「関心事」が隠ぺいしがち
– 深いモデルの探求の手掛りを見失う
• 同じ「ロジック」が複数サービスに重複する
– 変更コストがあがる
– モデルとコードの「成長の障害」になる
• 考え方とやり方
– メソッドの引数と型は「ドメインオブジェクト」にする
• long や Stringを使わない
– 基本は多態(ルールの場合ごとの切り替え)の道具
– それ以外の場合、リファクタリングの候補としておく
• より適切な置き場所を模索を続ける(良いモデルの探求)
77. ファーストクラスコレクション
• ListやSetをラップしたドメインオブジェクト
• Products
• PurchaseHistory
• 「一覧」や「履歴」という関心事の表現手段
– 一覧画面に対応するドメインオブジェクト
– 「一覧」は利用者の関心事が集中する場所
– 「一覧」の議論は、重要な関心事の発見の良い機会
• 一覧=SQLで複雑な問合せ?
– SQLの抽出条件は単純にして、微妙な抽出や問合せを、オ
ブジェクトにやらせる、という選択肢
– どちらがドメインの概念をうまく表現するか/発見できるか
– 変更があった時に、どちらが楽で安全か
78. 区分オブジェクト
• 振る舞いを持った Enum
• 区分ごとのロジックを別クラスに記述
• Java言語使用に組み込まれた
Strategy/Stateパターン
説明とコード例は、googleで
「場合わけの書き方あれこれ」で検索。
または「ソフトウェアデザイン9月号」
場合ごとのルールを理解し表現する道具
97. 「8章 ブレークスルー」を読む
• ブレークスルーの自分の経験を思い出す
– なんだ、こういうことか
– お、そうか
– 目からうろこ
• 変化のリズム
– 緩-緩-急、緩ー緩ー急、…
• 「緩」 は基本を地道に繰り返し、小さな変化を積み重ねる期間
• 「急」 は大きな変化に冷静に対処する期間
• 大きな変化の時
– 「発見の喜び」と「実験」と「実装」を冷静に制御する
– チームで納得して行動する
98. 第9章 暗黙的な概念を明示的にする
• 概念を掘り出す
– 言葉に耳を傾ける
– ぎこちなさを精査する
– 矛盾について熟考する
– 文献を読む
– 何度でも挑戦する
• それほど明確でない概念をモデル化する方法
– 明示的な制約
– ドメインオブジェクトとしてのプロセス
• 仕様(Specification)
100. 9章の補足
• 「制約」
– 制約が概念の輪郭の発見の手掛りになる
– 制約のなさに「便利さ」ではなく「気持ち悪さ」を感じよう
• String/LocalDate/BigDecimal/Collection/ …
• 「プロセス」
– オブジェクト指向の苦手な世界
– イベントストリームやリアクティブの考え方が武器になる
– 利用者の関心事を表現する武器
• 「仕様」 (Specification)
– 述語論理(AND/OR/NOT/EXIST/…)
– オブジェクト指向の苦手な世界
• Java 8 Predicate ?
– 良い実装の枠組み手に入れると、強力な武器になる
– 利用者の関心事を表現する武器
110. 第3部 まとめ
• 深いモデル
– ドメインについての深い理解を表現したモデル
– 利用者の「主要な関心事」の「明快な表現」
– 表面的な側面を捨て去る
– 利用する人たちの要望に機敏に対応
• 何をすべきか
– 「深いモデル」を目指した「リファクタリング」
– 「言葉」を使って「チーム」で発見/実験/改良
– 実験と成長のための「しなやかな設計」の工夫
113. 広い範囲で長期的に取り組む
• 意思決定がむずかしい
– 構成要素が多く、複雑に入り組んだ関係
– 複数のチーム間の交渉など「政治的」な要因の扱い
– 巨大で複雑なシステムの「全体的な秩序」の改善
– 巨大で複雑なシステムの「成長を続ける全体」
• 何をすべきか
– (このレベルでも)「言葉」を使った発見と改良に取り組む
– (このレベルでも)実装と結びつくモデルを探求する
• 現場でコードに責任を持つメンバーが中核になって進める
– 少しずつ「秩序」を改善する
– 少しずつ「全体」を成長させる
114. 第14章 モデルの整合性を維持する
• 境界づけられたコンテキスト
• 継続的な統合
• コンテキストマップ
• 境界づけられたコンテキスト間の関係
• 共有カーネル
• 顧客/供給者の開発者のチーム
• 順応者
• 腐敗防止層
• 別々の道
• 公開ホストサービス
• 公表された言語
• 象のモデルを統一する
• モデルコンテキストの戦略を選択する
• 変換
116. 第15章 蒸留
• コアドメイン
• 蒸留の拡大
• 汎用サブドメイン
• ドメインビジョン声明文
• 強調されたコア
• 凝集されたメカニズム
• 蒸留して宣言スタイルにする
• 隔離したコア
• 抽象化されたコア
• 深いモデルの蒸留
• リファクタリングの対象を選ぶ
118. 「中核」を探す準備
• かたまりにわける
– モジュールの設計と改善作業
– 汎用サブドメイン
• 独立性が高く、一般的な業務知識などをたよりに発見できるモ
ジュール
– 凝集されたメカニズム
• 技術的な関心事の隠ぺいを追求することで発見できるモジュール
– 「意図の明白なインタフェース」のみ公開される
• それぞれのモジュールの「意図」「役割」を明確にする
– 名前
– モジュール間の依存関係
– 「言葉」を使って検証と改良を続ける
119. 「コアドメイン」の実現
4つのレベル(成長の方向)
• ドメインビジョン声明文
– 言葉による「コアドメイン」の実験と改良
– 費用対効果が高い(チームが根本概念を共有する効果)
• 強調されたコア
– 実装の変更に取り組む前の実験/準備作業
– 既存の「モデル」で重要な点を強調してみる
• 本質的なオブジェクトを書きだしたり要約図を描いてみる
• ドキュメントがあれば、付箋やマーキングで強調してみる
• 隔離されたコア
– 重要な要素を、特定のモジュールに集める
• 「モジュール」構成のリファクタリング
• 抽象化されたコア
– 根本的な概念を、クラスやインタフェース宣言に抽出する
– 他の詳細が、この抽象化されたコアに依存するように設計する
121. 第16章 大規模な構造
• 進化する秩序
• システムのメタファ
• 責務のレイヤ
• 知識レベル
• 着脱可能コンポーネントフレームワーク
• 構造による制約にどの程度厳しくすべきか
• ふさわしい構造へのリファクタリング
124. 16章のパターンへのコメント
• メタファ
– わかりやすいが危険
• 責務のレイヤ
– 分析により比較的、論理的に発見できる
– データモデリングの考え方と手法が参考になる
• 知識レベル
– 判断ロジックがごちゃごちゃしたり、置き場所に迷う時
– 簡単な実験 XxxType と Xxx に分けてみる
• 従業員タイプと従業員
• 着脱可能なコンポーネントフレームワーク
– ここに至るまで熟成している間に環境がかわってしまいそう
– 適応型の開発スタイルだと、ここは目的地ではなく、結果
127. 現場での取り組み
• A社 システム全体/事業の実情/経営方針を理解する
一人の優秀な技術者が支えている会社
• 契約上は案件ごとのお手伝い
• 戦略的設計の実践を意識しながら支援中
• 会社の誕生の時からの長いお付き合い
• B社 サービスごとに担当がわかれた小さな技術者集団
• 森を見る意識とスキルの向上の支援
• これも契約上は案件ごとのお手伝い
• 昔の部下たち
• C社 森を見た「戦略」があり、少しずつ成長する「適応型」
の開発スタイルで活動できる技術部門
• 実戦のための、中核メンバーのさらなる育成とチーム力のアップのお
手伝い(コンサルティング契約)