第３週ドメイン駆動設計に戦略的に取り組む

2015年9月16日 増田(@masuda220)

ギルドワークス株式会社 取締役

有限会社システム設計 代表

DDDアライアンス 設立メンバ

３週連続ＤＤＤ 「ドメイン駆動設計」の要点と実践ノウハウ

そんな人のために …そんな人のために …

・読み解くのが困難・実践でどう活用するか迷っている・やってみたがうまくいかない

アジェンダ

• 戦略的な取り組みの事例

• 基本がたいせつ

• 第１４章 モデルの整合性を維持する

• 第１５章 蒸留

• 第１６章 大規模な構造

• 第１７章 戦略をまとめ上げる

• ３週連続DDDのまとめ

第４部 戦略的設計

３社での取り組みの事例

• 企業の人材採用／雇用支援システム

• 汎用プロダクトかつ個社対応

– 採用雇用は経営戦略であり企業の独自性が強い

• 会社としての成長とシステムの成長

創業から１０年のおつきあい

パートアルバイト領域

パートアルバイト領域

キャリア採用

アパレル特化求人サイト 個社対応

顧客：数百社

挑戦テーマ・深いモデル・しなやかな設計・成長を続ける全体

SBヒューマンキャピタル

• ソフトバンクグループの人材系サービス会社

• 切り口の異なる複数サービス

– 基本は「求人」「職務経歴」「応募」で同じだが…

• 他社サービスを含めさまざまな連携

１０年来のおつきあい

モデルの整合性の挑戦ネタの宝庫

• インターネットサービスプロバイダ

• 基幹システム

– レガシー

– 顧客、契約、請求、物流、サポート、…

– キャリア連携／販売チャネル連携

• ドメイン駆動設計で「太陽系戦略」に取組中

現場での支援活動２年継続中

ISP事業の基幹システムでの挑戦現場の問題意識と意欲的な活動勉強になる

取り組みの現実• HRソリューションズ

– システムも事業も実業務にも精通した一人の優秀な技術者と、案件ごとに、改善の取り組み

– 経営が変化とスピードを重視し実践している• システムづくりと運用が超たいへん

• SBヒューマンキャピタル– 短期的な課題、個別の課題解決に忙殺されがち– 現場レベルでの戦略的な取り組み意識の向上から

• ビッグローブ– 戦略的な取り組みの意欲と実践– 時間がかかるだろうが一歩一歩前進中

戦略的に取り組む

• 時間がかかる

• 関係者が多い

• 障害が多い

• すぐには見えない効果

• それでも取り組む動機

• 一歩一歩進む

• 基本に忠実に

ものづくり屋の本能良いもの、役に立つものをつくりたいビジネス上の期待に応える

誰がやるのか

• 意思決定と行動

– 開発チーム／現場の技術者

– 複数の開発チーム

• どうやって

– 言葉を使った意図の伝達

– さまざまな力関係とトレードオフの判断

• そのための膨大な知識の理解と整理

– 戦略を「コード」で表現する

戦略的に取り組む場合こそ基本がたいせつ

「基本」を戦略的に実践する

• 「オブジェクト指向」を戦略的に

• 「エクストリームプログラミング」を戦略的に

• 第１部の「三原則」を戦略的に

• 第２部の「基本スキル」を戦略的に

• 第３部の「深いモデルの探求」を戦略的に

「戦略的」•広い視野で

•多くの関係者で

•時間をかけて

「ドメイン駆動設計」の基本

この二つを組み合わせたソフトウェア開発。その成功と失敗の経験から学んだことをまとめたものが「ドメイン駆動設計」。

オブジェクト指向

エクストリームプログラミング

オブジェクト指向と「変更容易性」

• 抽象データ型／段階的抽象化

– プログラムを人間の発想に近づけると扱いやすい

• モジュラープログラミング

– 独立性の高い部品に分けると扱いやすい

• メッセージング

– 部品の組合せ型が柔軟だと扱いやすい

どのパラダイムにも共通する設計の考え方ドメイン層のコードは、たぶん似たものになる

LocalDate

日付を汎用的に扱う手段Java APIのレイヤ

int yearshort monthshort day

LocalDateの内部Java言語仕様のレイヤ

if( day > 31 ) …

DateOfBirth

「誕生日」に用途を限定した独自定義クラス「ドメイン層」の一級市民（ドメインオブジェクト）人間の発想

コンピュータの仕組み

抽象データ型／段階的な抽象化コードを人間の発想に近づける

Boolean 今月が誕生月()Days 誕生日まであと何日()

plusDays()plusMonths()

「モジュール化」と「メッセージング」

受付役

仲介役

回答役

経路情報専門家

判定役

おーい手伝って

後はまかせた

おーい考えて

おーい教えて

教えて

最短経路は…

独立性の高い部品

独立性の高い部品

独立性の高い部品

独立性の高い部品

独立性の高い部品

人間の営みと同じ仕組み必要に応じて最適チームを結成

「適応型」のソフトウェア開発開発のスタイル

方法論ソフトウェアの最終形（着地点）

開発サイクル

予測型ウォータフォール

事前に定義厳密に定義

固定分析/設計/製造

反復・漸進型

RUPそれなりに定義

反復ごとに精緻化

方向付/推敲/作成/移行

各フェーズで分析/設計/製造を、N回「反復」する

適応型XP

スクラムざっくりと定義

日々更新日、週、春夏秋冬

（人間の生活リズム）

ソフトウェアの開発スタイル• 「変更」との戦いの歴史

– 変更のコストとの戦い

– 変更のリスクとの戦い

• 「エクストリームプログラミング」は、積極的に「変化を目指す」開発スタイル

変更を管理する

変更を受入れる

変化を目指す

予測型 反復・漸進型 適応型

変化を目指す開発チーム• コミュニケーション

– 言葉を使って意図を伝える

• シンプリシティ– 複雑になるほど変化が難しくなることを知っている

• フィードバック– 経験／実験にもとづき進むべき道を探す

• 勇気– 行動する勇気、耐える勇気

• リスペクト– お互いの考えと行動に関心を持ち、かつ、尊重する

戦略的に取り組む

• 「オブジェクト指向」の変更容易性をより広く、より長期に

• 「エクストリームプログラミング」の適応型の開発をより広く、より長期に

第４部 戦略的設計に取組みながら、ここの理解と実践力を鍛える

第１部の３原則を戦略的に実践する

より広く、より長期に

第２章言葉を使った意図の伝達

第１章ドメインの知識をかみ砕く

第３章モデルと実装を結びつける

ドメインモデル

ドメインの膨大な情報をかみ砕き、蒸留して重要な関心事を鋭く説明する

選び抜かれたドメインの重要な関心事をコードで表現する

会話を繰り返して「要約」を改善する（重要点を明確にする）

「重要な語彙」をメンバーで合意する／共有する

活動の目的／背景

ドメインとソフトウェア

利用する人たちの活動と関心事

ソフトウェア戦略的設計では、視野をさらに広げる３社はここがある程度できている

モデル• 膨大な知識を「要約」したシンプルでわかりやすい説明

• モデリングのスキル＝「要約力」

–重要な要素を発見する力

–本質的でないものを削る力

–厳密に組み立てる力本質的でないものを削る力がほんとうに重要議論と行動が迷走しないために

３つの原則を戦略的に

• 第１章 知識をかみ砕く

– 戦略的な意思決定をし、適切に行動するためには、膨大な知識が必要

• 第２章 言葉を使う

– 戦略的な意思決定も、開発チームのメンバーの「言葉」を使ったコミュニケーションが基本

• 第３章 モデルと実装を結びつける

– 戦略も、コードで表現する

第２部の基本スキルを戦略的に実践する

ドメイン層に集中する

システム間連携もここに焦点をあてる。難しい…

関心事を「抽出」し関係に注目する

ひとつに見える対象から、関心事を抽出する。いろいろな可能性が広がる。一枚岩では動きがとれない。

第２部を広い範囲で長期的に

• 利用する人たちの関心事を隔離する– 「ドメイン層」

• 利用する人たちの関心事を「抽出」し「コード」で表現する– 「ドメインオブジェクト」

• 関心事の「モデル」（要約）に集中する– 機能視点で駆動しない

– データベース視点で駆動しない

– 画面視点で駆動しない

機能／データベース／画面の中核にある「関心事のモデル」を探す

第３部を戦略的に実践する

深い洞察に向かうリファクタリング

• 「深いモデル」を探求する

• 「しなやかな設計」を工夫する

• 焦点を絞る

• より広い範囲で

• より長期的に

概念を掘り出す努力していますか？

• 言葉に耳を傾ける

• ぎこちなさを精査する

• 矛盾について熟考する

• 文献を読む

• 何度でも挑戦する

ドメイン駆動設計の実践のキモこれを広い視野で、より複雑な問題を対象に長期的に実践するのが戦略的な設計の基本９章を読みながら、個人やチームで振り返りを

多くのメンバー／チームの日常の習慣になってくるとその集積が戦略的に効いてくる

深いモデル/しなやかな設計

• ドメイン層のごく一部での取り組み

• ドメイン層全体に波及する

– 業務知識を要約し鋭く説明できる力

– ソフトウェアの変更容易性を向上するテクニック

• システム全体に波及する– プレゼンテーション層／アプリケーション層／データソース層

• 連携するシステム全てに波及する

チームの全員の考え方と行動に波及するすべての関係者の考え方と行動に波及する

第４部 戦略的な設計

第１４章 モデルの整合性第１５章 蒸留第１６章 大規模な構造第１７章 戦略をまとめ上げる

第１４章モデルの整合性を維持する

第１４章の概要

• 境界づけられたコンテキスト

• 継続的な統合

• コンテキストマップ

• 境界づけられたコンテキスト間の関係

• 象のモデルを統一する

• モデルコンテキスト戦略を選択する

• 関係を変更していく

境界づけられたコンテキスト

大きな部品を特定する

• 一つのモデルとして独立していそうな範囲

– 開発チーム

– 運用チーム

– コードベース

– データベーススキーマ…

• ひとつのモデルが適用できる範囲の制限

• モデルの一貫性を保つ努力をする範囲の限定

• チームの「言葉」の通用する範囲に注目する

これらが分かれているが、１つのモデルということはないひとつの範囲に複数のモデルが生まれてしまうことはある

ひとつのコンテキスト内で継続的な統合をする

• チーム内（境界づけられたコンテキスト内）の「一貫性」を維持する

• 「概念」は、別々の人の頭の中でばらばらに進化をはじめることに、いつも注意する

• コードの統合に成功しても、「理解」が統合できていないリスクを気に掛ける

• 複数のコンテキスト間の関係を扱いやすくするための前提

コンテキストマップ

コンテキストコンテキスト

コンテキスト

モデル

モデル

モデル

「ドメイン層」の「モデル」間の関係現実がどうなっているかを知る

関係者でスケッチしてみると「気づき」が多く、非常に効果的季節単位くらいに繰り返したい

コンテキスト間の関係

別々の道

チームのコミュニケーションの意欲と能力

関連するシステムに対する制御

腐敗防止層

順応者

顧客/供給者チーム

公開ホストサービス

共有カーネル

単一の境界づけられた

コンテキスト

共同経営

現実を直視なぜそうなっているかを理解する

第１４章の要点

• 現実を直視する

– 関係者で共通の理解に

– 背景や歴史まで視野を広げて

– ある種の「美しさ」

• 開発チームによる意思決定と行動

– チーム内

– チーム間

• 統合による利益と調整コストのトレードオフ

密接な関係を実現する

• 複数のコンテキスト（チーム）を単一のコンテキスト（チーム）に統合にする

• 共同経営

• 共有カーネル（複数チームで共同開発）

密接な関係のメリット密接な関係のコスト短期・長期局所・全体

明確な関係を打ち立てる

• 顧客／供給者のチーム

• 公開ホストサービス

• 公表された言語

関係を確立するメリット関係を維持するコスト短期・長期局所・全体

コミュニケーションしながらどこかに合わせる

独立した別のチーム

• 別々の道

• 順応者

• 腐敗防止層

独立しているメリット独立により発生するコスト短期・長期局所・全体

コンテキスト間の関係の意思決定

「意思決定」とは、コードでどう書くかを決めること

戦略を選択する時の考えどころ

• チームでの意思決定と、より上層での意思決定• コンテキストに自らの身を置く• 境界を変換する• 変更できないものを受入れる• 外部システムとの関係• 設計中のシステム• 別のモデルの特殊な要求を満たす• デプロイ• トレードオフ• すでにプロジェクトが進行中の場合

「現実の直視」「トレードオフ」

「実践的な判断」熟読すべし

関係者で議論すべし

page.391～398

変換（関係を変えていく）• コンテキストをマージする

– 別々の道 ⇒ 共有カーネル

– 共有カーネル ⇒ 継続的な統合

• レガシーシステムを段階的に廃止する

• 公開ホストサービス ⇒ 公表された言語

「現実の直視」「トレードオフ」

「実践的な判断」熟読すべし

関係者で議論すべし

page.398～404

第１４章 まとめ

• ひとつのコンテキスト内部のモデルの一貫性を維持する

• 現実のコンテキストマップを作る

• コンテキスト間の選択肢を共通理解にする

• 現実を直視する

• トレードオフを考える

• 関係者で活発に意見交換する

関係者の活発な意見交換がすべての戦略的設計の前提「意思決定」を、必ず「コード」で表現すること

第１５章 蒸留

第15章の概要• コアドメイン• 蒸留の拡大• 汎用サブドメイン• ドメインビジョン声明文• 強調されたコア• 凝集されたメカニズム• 蒸留して宣言スタイルにする• 隔離したコア• 抽象化されたコア• 深いモデルの蒸留• リファクタリングの対象を選ぶ

コアドメイン選択と集中

中核中の中核を見究める• 中心になる問題に集中し、枝葉末節の海でおぼ

れないようにする– 「ドメインモデル」自体が、重要な関心事のかたまり

– 「ドメインモデル」が複雑になってきた時に、さらに、その「中核」部分を見究める活動

– 高度な「要約力」

– すこしずつ、実験とフィードバックを繰り返しながら「コアドメイン」を識別していく

• ビジネスへの影響の大きさ／ソフトウェアの価値– 「第１章 知識をかみ砕く」を高度に実践する

「中核」の探し方

• 「かたまり」を「抽出」する

• それぞれの「かたまり」の「意図」を明確にする

かたまりを「抽出」する

• 「汎用サブドメイン」

– 独立性が高く、一般的な業務知識などをたよりに発見できる「かたまり」

• 「凝集されたメカニズム」

– 技術的な関心事の隠ぺいを追求することで発見できる「かたまり」

– 「意図の明白なインタフェース」のみ公開する

「かたまり」の「意図」を明確に

• 名前

• 「かたまり」間の依存関係

• 「言葉」を使って「名前」と「関係」の検証と改良を続ける

– ＡはＢを使う

– ＡはＢに依存する

– ＡはＢを詳細化する…

「関係」をもっと知識豊富な言葉に

「コアドメイン」の具体化４つの段階

• ドメインビジョン声明文

• 強調されたコア

• 隔離されたコア

• 抽象化されたコア

これが書けない語れない

「ドメインビジョン声明文」• 言葉を使って「コアドメイン」を表現してみる

• 費用対効果が高い– 簡単に取り掛かれる

– 簡単に複数案を作れる

– 簡単に変更できる

• チームが根本概念を共有する効果

• 正しく表現する– 語尾をあいまいにしない

– だらだら語らない

– 「あれ」「これ」「それ」を使わない

– 「カタカナ言葉」を使わない

「強調されたコア」• 実装は変更しない

• 既存の「モデル」で重要な点を強調

– 本質的なオブジェクトを書きだしたり要約図を描いてみる

– ドキュメントがあれば、付箋やマーキングで強調してみる

• ラフスケッチと「意見交換」

– 強調した点を「正しく」表現してみる

• チームで「主要な関心事」を共有する手段

「隔離されたコア」• コードを実際に変える

• 重要な要素を、特定のモジュールに集める

• リファクタリング– モジュール構成

– モジュール名

– クラス名

– メソッド名／引数の型／返す型…

• 深いモデルをコードに反映

• しなやかな設計にして変更に機敏に対応

「抽象化されたコア」• 根本的な概念を、クラスやインタフェース宣言

に「抽出」する

• 他の詳細は、この抽象化されたコアに依存するように設計する

• 根本の概念は安定しているが、詳細の変更が頻繁に発生する時に、効果を発揮する

「深いモデル」の探求の帰結「しなやかな設計」の追求の帰結

第１５章 まとめ

• 「中核の関心事」を、「コード」を書く人間が的確に理解する効果

• 「中核」の関心事を、「コード」で表現する威力

• 少しずつ地道な改善活動– 「チーム」で続ける

– 大勢で、長期的に

– 協力のための手段「言葉」

– 「第3部 深い洞察に向かうリファクタリング」の高度な実践

第１6章 大規模な構造

第１６章の概要

• 進化する秩序

• システムのメタファ

• 責務のレイヤ

• 知識レベル

• 着脱可能コンポーネントフレームワーク

• 構造による制約にどの程度厳しくすべきか

• ふさわしい構造への「リファクタリング」

主題：「森を見る」力をつける

• コードに責任を持つ開発者たちが、「全体を俯瞰」し理解する効果

• 大きく複雑なシステムの「秩序」を少しずつ改善していくための手掛りの発見

• 関係者が全体の構造を理解し議論するための「枠組み」を手に入れる効果

「森」を少しずつ成長させていく

• 「秩序」を改善する

• 「全体」を成長させる

• 時間をかけて

• 何世代にもわたって

• 「有機的な秩序」を壊さないように

メタファー

• チーム内の共通理解に強力な武器になることがある

• 「わかったつもり」で、実際には異なる理解になる危険性も高い

• 「カタカナ」は厳禁

• 「キャッチフレーズ」は厳禁

• いつでも、だれでも同じ言い回しになる「言葉」であること

責務のレイヤ• モジュール（独立性の高い部品）の抽出が前提• モジュール間の「依存関係」に注目して整理する• 候補

– 意思決定– ポリシー– 確約（コミットメント）– 業務（オペレーション／トランザクション）– 潜在能力（リソース）

• 始めは、上下２層にわけることから– 層が多いことが役に立つわけではない

• 参照の方向性を一方向に限定する実験は効果的

最初は不自然な設計に見えるが、ブレークスルーのきっかになることがある

役に立つ着眼点• 時間軸での依存関係

– 先に存在すべきオブジェクト

• 変更の理由／変化のサイクル– 頻繁で継続的／短い イベント系

– 時々／ゆっくり リソース系

– ほぼ固定 制度

• 「責任分界点」とそれぞれの「責任」– 契約/利用規約

– 職務分掌規程

• 「依頼役」と「サービス提供役」

比較的、体系的に学べる

「知識レベル」

• 判断ロジックがごちゃごちゃしたり、置き場所に迷う時

• 簡単な実験

– XxxType と Xxx に分けてみる

– 例：従業員タイプと従業員

• 「レイヤ構造」ではない

– 参照を一方向に限定する必要はない

１６章のパターンへのコメント

• メタファ– わかりやすいが危険

• 責務のレイヤ– 分析により比較的、論理的に発見できる– データモデリングなどの考え方と手法も参考になる

• 知識レベル– 判断ロジックがごちゃごちゃしたり、置き場所に迷う時

• 着脱可能なコンポーネントフレームワーク– ここまで熟成している間に環境がかわってしまう？– 適応型の開発スタイルでは、目的地ではなく結果

ふさわしい構造へのリファクタリング

• ミニマリズム– いちどに大きく取り組まない

• コミュニケーションと自己規律– ドキュメントでは一貫性は維持できない

– チームの通常の会話では、全体の構造を共有できない（視野の経験の差が大きい）

– 「戦略」を「言葉」と「コード」で表現する

• 繰り返し形を変えることでしなやかな設計になる

• 継続的な蒸留（補助的な構造の削除）による負荷の軽減

設計の改善

第１６章のまとめ• モデルが大きく複雑になってきたときの整理の

考え方とやり方

• ビジネスモデリングやアナリシスパターンの文献から学べることも多い

• 蒸留（深いモデルの探求）とリファクタリング（しなやかな設計の追求）を、広い範囲で、長期的に取り組むための手段

第１７章戦略をまとめ上げる

第１７章の概要

• 「大規模な構造」と「境界づけられたコンテキスト」を組み合わせる

• 「大規模な構造」と「蒸留を組み合わせる」

• まず評価する

• 誰が戦略を決定するのか

• 戦略的設計の「意思決定」を行うために欠かせない６つのこと

戦略的な設計に取り組むためにはまず現状を正しく把握する

• コンテキストマップを描くこと

– あいまいな点や怪しいところを発見する

• 「言葉」の使われ方を評価する

• 何が重要であるかの理解度

• モデル駆動設計に向いた技術を使っているか

• 開発者の技術スキル

• 開発者のドメインへの「関心」の度合い

さまざまな厳しい現実と誠実に向き合う

誰が戦略を策定するのか

• エクストリームプログラミングの「アーキテクト」

– 通常はプログラムタスクを担当する開発者

• 「ドメイン層」を開発するチームから、システムの全体的な構造が現れる

– 全体的な構造も「ドメインモデル」が駆動する

• 「アプリケーション開発チーム」に貢献する「アーキテクチャチーム」

最初から優れたアーキテクトはいない現場で、実践の中で才能を見出し、育てて行く。（自分も含めて）

戦略設計上の意思決定かかせない６つのこと

• 意思決定はチーム全体に伝える

• 意思決定のプロセスにフィードバックを組み込む

• 計画は変化し進化を続ける

• アーキテクチャチームが優秀な人材を吸い上げてはいけない

• ミニマリズムと謙虚さ

• オブジェクトはスペシャリスト、開発者はジェネラリスト

第１７章へのコメント

• コードを変更する人間が「戦略」を理解し、実行に移すことがもっとも効果的

• 「戦略」も「言葉」による意図の伝達と実験が基本

– 多くの人たちが長期的に取り組むための武器

• 変化に対応し、少しずつ成長を続ける全体

– 「適応型」の開発スタイル

– 「戦略」こそ「日々」の変化の積み重ね

– 進化を続ける「有機的な秩序」

– 「まちづくりの新しい理論」

第３週「戦略的な設計」のまとめ

• 基本たいせつ– オブジェクト指向 エクストリームプログラミング

– 第１部の３原則（知識・言葉・コード）

– 第２部のモデルと実装を結びつける基本スキル

– 第３部の深いモデルの探求としなやか設計の追求

• 第１４章 境界と関係を明確にする

• 第１５章 「中核」に焦点をあてる

• 第１６章 大きな単位のモジュール化/依存関係

• 第１７章 進化する秩序、成長する全体

３週連続DDDまとめ

３週連続DDD

• 第１週 ドメイン駆動設計の基本を理解する

• 第２週 深いモデルの探求

• 第３週 戦略的に取り組む

「ドメイン駆動設計」とは

厳しい現実の中で、ソフトウェア設計を習得しようと奮闘してきた技術者の物語。

不完全な状況の中で、抽象的な設計原則を、現実のソフトウェアに適用するための助言。

「日本語版への序文」 by エリック・エヴァンス

エヴァンスは、ソフトウェア開発の成功も失敗も味わってきた。この本は、エヴァンスが成功と失敗の両方から学んだ教訓を伝えている。

「序文」 by マーチン・ファウラー

厳しい現実だらけの現場でより良いソフトウェアを作るために「実践的な設計」の勉強を続けよう

• どんな状況でも改善できる

• どんなときでも「あなた」から改善を始められる

• どんなときでも「今日」から改善を始められる

エクストリームプログラミングの「はじめに」に記されたケント・ベックのメッセージ

ありがとうございました

【広告】DDDの３原則を体験的に学ぶ

• 【DDD Alliance】第2回 実践的ドメイン駆動設計ワークショップ

• http://ddd-alliance0002.peatix.com

• ９月２６日（土）と１０月３日（土）の２日コース

• 有償（１万５千円 税抜）

• 内容– 「要約力」

– 「ドメインの創造的な学び方」

– 「言葉」を使ったモデリングと設計の体験学習