Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
第3週
ドメイン駆動設計に
戦略的に取り組む
2015年9月16日 増田(@masuda220)
ギルドワークス株式会社 取締役
有限会社システム設計 代表
DDDアライアンス 設立メンバ
3週連続DDD 「ドメイン駆動設計」の要点と実践ノウハウ
そんな人のために …そんな人のために …
・読み解くのが困難
・実践でどう活用するか迷っている
・やってみたがうまくいかない
アジェンダ
• 戦略的な取り組みの事例
• 基本がたいせつ
• 第14章 モデルの整合性を維持する
• 第15章 蒸留
• 第16章 大規模な構造
• 第17章 戦略をまとめ上げる
• 3週連続DDDのまとめ
第4部 戦略的設計
3社での取り組みの事例
• 企業の人材採用/雇用支援システム
• 汎用プロダクトかつ個社対応
– 採用雇用は経営戦略であり企業の独自性が強い
• 会社としての成長とシステムの成長
創業から10年のおつきあい
パートアルバイト領域
パートアルバイト領域
キャリア採用
ア...
SBヒューマンキャピタル
• ソフトバンクグループの人材系サービス会社
• 切り口の異なる複数サービス
– 基本は「求人」「職務経歴」「応募」で同じだが…
• 他社サービスを含めさまざまな連携
10年来のおつきあい
モデルの整合性の
挑戦ネタの...
• インターネットサービスプロバイダ
• 基幹システム
– レガシー
– 顧客、契約、請求、物流、サポート、…
– キャリア連携/販売チャネル連携
• ドメイン駆動設計で「太陽系戦略」に取組中
現場での支援活動2年
継続中
ISP事業の基幹シス...
取り組みの現実
• HRソリューションズ
– システムも事業も実業務にも精通した一人の優秀な
技術者と、案件ごとに、改善の取り組み
– 経営が変化とスピードを重視し実践している
• システムづくりと運用が超たいへん
• SBヒューマンキャピタル...
戦略的に取り組む
• 時間がかかる
• 関係者が多い
• 障害が多い
• すぐには見えない効果
• それでも取り組む動機
• 一歩一歩進む
• 基本に忠実に
ものづくり屋の本能
良いもの、役に立つものをつくりたい
ビジネス上の期待に応える
誰がやるのか
• 意思決定と行動
– 開発チーム/現場の技術者
– 複数の開発チーム
• どうやって
– 言葉を使った意図の伝達
– さまざまな力関係とトレードオフの判断
• そのための膨大な知識の理解と整理
– 戦略を「コード」で表現する
戦略的に取り組む場合こそ
基本がたいせつ
「基本」を戦略的に実践する
• 「オブジェクト指向」を戦略的に
• 「エクストリームプログラミング」を戦略的に
• 第1部の「三原則」を戦略的に
• 第2部の「基本スキル」を戦略的に
• 第3部の「深いモデルの探求」を戦略的に
「戦略的」
•広い視野で
•多くの関係者で
•時間をかけて
「ドメイン駆動設計」の基本
この二つを組み合わせたソフトウェア開発。
その成功と失敗の経験から学んだことをまと
めたものが「ドメイン駆動設計」。
オブジェクト指向
エクストリームプログラミング
オブジェクト指向と「変更容易性」
• 抽象データ型/段階的抽象化
– プログラムを人間の発想に近づけると扱いやすい
• モジュラープログラミング
– 独立性の高い部品に分けると扱いやすい
• メッセージング
– 部品の組合せ型が柔軟だと扱いやす...
LocalDate
日付を汎用的に扱う手段
Java APIのレイヤ
int year
short month
short day
LocalDateの内部
Java言語仕様のレイヤ
if( day > 31 ) …
DateOfBirth
「...
「モジュール化」と「メッセージング」
受付役
仲介役
回答役
経路情報
専門家
判定役
おーい
手伝って
後は
まかせた
おーい
考えて
おーい
教えて
教えて
最短経路は…
独立性の高い部品
独立性の高い部品
独立性の高い部品
独立性の高い部...
「適応型」のソフトウェア開発
開発の
スタイル
方法論
ソフトウェアの
最終形(着地点)
開発サイクル
予測型
ウォータ
フォール
事前に定義
厳密に定義
固定
分析/設計/製造
反復・
漸進型
RUP
それなりに定義
反復ごとに精緻化
方向付...
ソフトウェアの開発スタイル
• 「変更」との戦いの歴史
– 変更のコストとの戦い
– 変更のリスクとの戦い
• 「エクストリームプログラミング」は、積極的に
「変化を目指す」開発スタイル
変更を
管理する
変更を
受入れる
変化を
目指す
予測...
変化を目指す開発チーム
• コミュニケーション
– 言葉を使って意図を伝える
• シンプリシティ
– 複雑になるほど変化が難しくなることを知っている
• フィードバック
– 経験/実験にもとづき進むべき道を探す
• 勇気
– 行動する勇気、耐え...
戦略的に取り組む
• 「オブジェクト指向」の変更容易性
をより広く、より長期に
• 「エクストリームプログラミング」の
適応型の開発をより広く、より長
期に
第4部 戦略的設計に取組みながら、ここの理解と実践力を鍛える
第1部の3原則を
戦略的に実践する
より広く、より長期に
第2章
言葉を使った意図の伝達
第1章
ドメインの知識をかみ砕く
第3章
モデルと実装を結びつける
ドメイン
モデル
ドメインの
膨大な情報を
かみ砕き、蒸留して
重要な関心事を
鋭く説明する
選び抜かれた
ドメインの重要...
活動の目的/背景
ドメインとソフトウェア
利用する人たちの
活動と関心事
ソフトウェア
戦略的設計では、視野をさらに広げる
3社はここがある程度できている
モデル
• 膨大な知識を「要約」した
シンプルでわかりやすい説明
• モデリングのスキル=「要約力」
–重要な要素を発見する力
–本質的でないものを削る力
–厳密に組み立てる力
本質的でないものを削る力がほんとうに重要
議論と行動が迷走しないた...
3つの原則を戦略的に
• 第1章 知識をかみ砕く
– 戦略的な意思決定をし、適切に行動するためには、
膨大な知識が必要
• 第2章 言葉を使う
– 戦略的な意思決定も、開発チームのメンバーの
「言葉」を使ったコミュニケーションが基本
• 第3章...
第2部の基本スキルを
戦略的に実践する
ドメイン層に集中する
システム間連携も
ここに焦点をあてる。
難しい…
関心事を「抽出」し
関係に注目する
ひとつに見える対象から、
関心事を抽出する。
いろいろな可能性が広がる。
一枚岩では動きがとれない。
第2部を広い範囲で長期的に
• 利用する人たちの関心事を隔離する
– 「ドメイン層」
• 利用する人たちの関心事を「抽出」し「コード」
で表現する
– 「ドメインオブジェクト」
• 関心事の「モデル」(要約)に集中する
– 機能視点で駆動しない...
第3部を
戦略的に実践する
深い洞察に向かうリファクタリング
• 「深いモデル」を探求する
• 「しなやかな設計」を工夫する
• 焦点を絞る
• より広い範囲で
• より長期的に
概念を掘り出す努力していますか?
• 言葉に耳を傾ける
• ぎこちなさを精査する
• 矛盾について熟考する
• 文献を読む
• 何度でも挑戦する
ドメイン駆動設計の実践のキモ
これを広い視野で、より複雑な問題を対象に
長期的に実践するのが戦略的...
深いモデル/しなやかな設計
• ドメイン層のごく一部での取り組み
• ドメイン層全体に波及する
– 業務知識を要約し鋭く説明できる力
– ソフトウェアの変更容易性を向上するテクニック
• システム全体に波及する
– プレゼンテーション層/アプリ...
第4部 戦略的な設計
第14章 モデルの整合性
第15章 蒸留
第16章 大規模な構造
第17章 戦略をまとめ上げる
第14章
モデルの整合性を維持する
第14章の概要
• 境界づけられたコンテキスト
• 継続的な統合
• コンテキストマップ
• 境界づけられたコンテキスト間の関係
• 象のモデルを統一する
• モデルコンテキスト戦略を選択する
• 関係を変更していく
境界づけられたコンテキスト
大きな部品を特定する
• 一つのモデルとして独立していそうな範囲
– 開発チーム
– 運用チーム
– コードベース
– データベーススキーマ
…
• ひとつのモデルが適用できる範囲の制限
• モデルの一貫性を保つ努力...
ひとつのコンテキスト内で
継続的な統合をする
• チーム内(境界づけられたコンテキスト内)の
「一貫性」を維持する
• 「概念」は、別々の人の頭の中でばらばらに進
化をはじめることに、いつも注意する
• コードの統合に成功しても、「理解」が統合...
コンテキストマップ
コンテキスト
コンテキスト
コンテキスト
モデル
モデル
モデル
「ドメイン層」の「モデル」間の関係
現実がどうなっているかを知る
関係者でスケッチしてみると
「気づき」が多く、非常に効果的
季節単位くらいに繰り返したい
コンテキスト間の関係
別々の道
チームのコミュニケーションの意欲と能力
関
連
す
る
シ
ス
テ
ム
に
対
す
る
制
御
腐敗防止層
順応者
顧客/供給者
チーム
公開ホスト
サービス
共有カーネル
単一の
境界づけられた
コンテキスト
...
第14章の要点
• 現実を直視する
– 関係者で共通の理解に
– 背景や歴史まで視野を広げて
– ある種の「美しさ」
• 開発チームによる意思決定と行動
– チーム内
– チーム間
• 統合による利益と調整コストのトレードオフ
密接な関係を実現する
• 複数のコンテキスト(チーム)を単一のコンテキ
スト(チーム)に統合にする
• 共同経営
• 共有カーネル(複数チームで共同開発)
密接な関係のメリット
密接な関係のコスト
短期・長期
局所・全体
明確な関係を打ち立てる
• 顧客/供給者のチーム
• 公開ホストサービス
• 公表された言語
関係を確立するメリット
関係を維持するコスト
短期・長期
局所・全体
コミュニケーションしながら
どこかに合わせる
独立した別のチーム
• 別々の道
• 順応者
• 腐敗防止層
独立しているメリット
独立により発生するコスト
短期・長期
局所・全体
コンテキスト間の関係の
意思決定
「意思決定」とは、コードでどう書くかを決めること
戦略を選択する時の考えどころ
• チームでの意思決定と、より上層での意思決定
• コンテキストに自らの身を置く
• 境界を変換する
• 変更できないものを受入れる
• 外部システムとの関係
• 設計中のシステム
• 別のモデルの特殊な要求を満た...
変換(関係を変えていく)
• コンテキストをマージする
– 別々の道 ⇒ 共有カーネル
– 共有カーネル ⇒ 継続的な統合
• レガシーシステムを段階的に廃止する
• 公開ホストサービス ⇒ 公表された言語
「現実の直視」
「トレードオフ」
「...
第14章 まとめ
• ひとつのコンテキスト内部のモデルの一貫性を
維持する
• 現実のコンテキストマップを作る
• コンテキスト間の選択肢を共通理解にする
• 現実を直視する
• トレードオフを考える
• 関係者で活発に意見交換する
関係者の活...
第15章 蒸留
第15章の概要
• コアドメイン
• 蒸留の拡大
• 汎用サブドメイン
• ドメインビジョン声明文
• 強調されたコア
• 凝集されたメカニズム
• 蒸留して宣言スタイルにする
• 隔離したコア
• 抽象化されたコア
• 深いモデルの蒸留
• ...
コアドメイン
選択と集中
中核中の中核を見究める
• 中心になる問題に集中し、枝葉末節の海でおぼ
れないようにする
– 「ドメインモデル」自体が、重要な関心事のかたまり
– 「ドメインモデル」が複雑になってきた時に、さらに、そ
の「中核」部分を見究める活動
– 高度な「...
「中核」の探し方
• 「かたまり」を「抽出」する
• それぞれの「かたまり」の「意図」を明確にする
かたまりを「抽出」する
• 「汎用サブドメイン」
– 独立性が高く、一般的な業務知識などをたよりに
発見できる「かたまり」
• 「凝集されたメカニズム」
– 技術的な関心事の隠ぺいを追求することで発見
できる「かたまり」
– 「意図の明白なイン...
「かたまり」の「意図」を明確に
• 名前
• 「かたまり」間の依存関係
• 「言葉」を使って「名前」と「関係」の検証と改
良を続ける
– AはBを使う
– AはBに依存する
– AはBを詳細化する
…
「関係」をもっと知識豊富な言葉に
「コアドメイン」の具体化
4つの段階
• ドメインビジョン声明文
• 強調されたコア
• 隔離されたコア
• 抽象化されたコア
これが書けない
語れない
「ドメインビジョン声明文」
• 言葉を使って「コアドメイン」を表現してみる
• 費用対効果が高い
– 簡単に取り掛かれる
– 簡単に複数案を作れる
– 簡単に変更できる
• チームが根本概念を共有する効果
• 正しく表現する
– 語尾をあいまい...
「強調されたコア」
• 実装は変更しない
• 既存の「モデル」で重要な点を強調
– 本質的なオブジェクトを書きだしたり要約図を描い
てみる
– ドキュメントがあれば、付箋やマーキングで強調し
てみる
• ラフスケッチと「意見交換」
– 強調した...
「隔離されたコア」
• コードを実際に変える
• 重要な要素を、特定のモジュールに集める
• リファクタリング
– モジュール構成
– モジュール名
– クラス名
– メソッド名/引数の型/返す型
…
• 深いモデルをコードに反映
• しなやか...
「抽象化されたコア」
• 根本的な概念を、クラスやインタフェース宣言
に「抽出」する
• 他の詳細は、この抽象化されたコアに依存す
るように設計する
• 根本の概念は安定しているが、詳細の変更が
頻繁に発生する時に、効果を発揮する
「深いモデル...
第15章 まとめ
• 「中核の関心事」を、「コード」を書く人間が的
確に理解する効果
• 「中核」の関心事を、「コード」で表現する威力
• 少しずつ地道な改善活動
– 「チーム」で続ける
– 大勢で、長期的に
– 協力のための手段「言葉」
– ...
第16章 大規模な構造
第16章の概要
• 進化する秩序
• システムのメタファ
• 責務のレイヤ
• 知識レベル
• 着脱可能コンポーネントフレームワーク
• 構造による制約にどの程度厳しくすべきか
• ふさわしい構造への「リファクタリング」
主題:「森を見る」力をつける
• コードに責任を持つ開発者たちが、「全体を俯
瞰」し理解する効果
• 大きく複雑なシステムの「秩序」を少しずつ改
善していくための手掛りの発見
• 関係者が全体の構造を理解し議論するための
「枠組み」を手に入れる...
「森」を少しずつ成長させていく
• 「秩序」を改善する
• 「全体」を成長させる
• 時間をかけて
• 何世代にもわたって
• 「有機的な秩序」を壊さないように
メタファー
• チーム内の共通理解に強力な武器になること
がある
• 「わかったつもり」で、実際には異なる理解に
なる危険性も高い
• 「カタカナ」は厳禁
• 「キャッチフレーズ」は厳禁
• いつでも、だれでも同じ言い回しになる「言葉」
である...
責務のレイヤ
• モジュール(独立性の高い部品)の抽出が前提
• モジュール間の「依存関係」に注目して整理する
• 候補
– 意思決定
– ポリシー
– 確約(コミットメント)
– 業務(オペレーション/トランザクション)
– 潜在能力(リソー...
役に立つ着眼点
• 時間軸での依存関係
– 先に存在すべきオブジェクト
• 変更の理由/変化のサイクル
– 頻繁で継続的/短い イベント系
– 時々/ゆっくり リソース系
– ほぼ固定 制度
• 「責任分界点」とそれぞれの「責任」
– 契約/利...
「知識レベル」
• 判断ロジックがごちゃごちゃしたり、置き場所に
迷う時
• 簡単な実験
– XxxType と Xxx に分けてみる
– 例:従業員タイプと従業員
• 「レイヤ構造」ではない
– 参照を一方向に限定する必要はない
16章のパターンへのコメント
• メタファ
– わかりやすいが危険
• 責務のレイヤ
– 分析により比較的、論理的に発見できる
– データモデリングなどの考え方と手法も参考になる
• 知識レベル
– 判断ロジックがごちゃごちゃしたり、置き場所に...
ふさわしい構造へのリファクタリング
• ミニマリズム
– いちどに大きく取り組まない
• コミュニケーションと自己規律
– ドキュメントでは一貫性は維持できない
– チームの通常の会話では、全体の構造を共有できな
い(視野の経験の差が大きい)
...
第16章のまとめ
• モデルが大きく複雑になってきたときの整理の
考え方とやり方
• ビジネスモデリングやアナリシスパターンの文
献から学べることも多い
• 蒸留(深いモデルの探求)とリファクタリング(し
なやかな設計の追求)を、広い範囲で、長...
第17章
戦略をまとめ上げる
第17章の概要
• 「大規模な構造」と「境界づけられたコンテキス
ト」を組み合わせる
• 「大規模な構造」と「蒸留を組み合わせる」
• まず評価する
• 誰が戦略を決定するのか
• 戦略的設計の「意思決定」を行うために欠か
せない6つのこと
戦略的な設計に取り組むためには
まず現状を正しく把握する
• コンテキストマップを描くこと
– あいまいな点や怪しいところを発見する
• 「言葉」の使われ方を評価する
• 何が重要であるかの理解度
• モデル駆動設計に向いた技術を使っているか
...
誰が戦略を策定するのか
• エクストリームプログラミングの「アーキテクト」
– 通常はプログラムタスクを担当する開発者
• 「ドメイン層」を開発するチームから、システム
の全体的な構造が現れる
– 全体的な構造も「ドメインモデル」が駆動する
•...
戦略設計上の意思決定
かかせない6つのこと
• 意思決定はチーム全体に伝える
• 意思決定のプロセスにフィードバックを組み込む
• 計画は変化し進化を続ける
• アーキテクチャチームが優秀な人材を吸い上げて
はいけない
• ミニマリズムと謙虚さ...
第17章へのコメント
• コードを変更する人間が「戦略」を理解し、実行に移
すことがもっとも効果的
• 「戦略」も「言葉」による意図の伝達と実験が基本
– 多くの人たちが長期的に取り組むための武器
• 変化に対応し、少しずつ成長を続ける全体
–...
第3週「戦略的な設計」のまとめ
• 基本たいせつ
– オブジェクト指向 エクストリームプログラミング
– 第1部の3原則(知識・言葉・コード)
– 第2部のモデルと実装を結びつける基本スキル
– 第3部の深いモデルの探求としなやか設計の追求
•...
3週連続DDD
まとめ
3週連続DDD
• 第1週 ドメイン駆動設計の基本を理解する
• 第2週 深いモデルの探求
• 第3週 戦略的に取り組む
「ドメイン駆動設計」とは
厳しい現実の中で、ソフトウェア設計を習得しよ
うと奮闘してきた技術者の物語。
不完全な状況の中で、抽象的な設計原則を、
現実のソフトウェアに適用するための助言。
「日本語版への序文」 by エリック・エヴァンス
エヴァ...
厳しい現実だらけの現場で
より良いソフトウェアを作るために
「実践的な設計」の勉強を続けよう
• どんな状況でも改善できる
• どんなときでも「あなた」から改善を始められる
• どんなときでも「今日」から改善を始められる
エクストリームプログラミングの
「はじめに」に記された
ケント・ベックのメッセージ
ありがとうございました
【広告】DDDの3原則を体験的に学ぶ
• 【DDD Alliance】
第2回 実践的ドメイン駆動設計ワークショップ
• http://ddd-alliance0002.peatix.com
• 9月26日(土)と10月3日(土)の2日コース
...
Upcoming SlideShare
Loading in …5
×

3週連続DDDその3 ドメイン駆動設計 戦略的設計

8,522 views

Published on

「ドメイン駆動設計」の第4部の概要と理解の手がかり。現場での実践経験から。

Published in: Software
  • Be the first to comment

3週連続DDDその3 ドメイン駆動設計 戦略的設計

  1. 1. 第3週 ドメイン駆動設計に 戦略的に取り組む 2015年9月16日 増田(@masuda220) ギルドワークス株式会社 取締役 有限会社システム設計 代表 DDDアライアンス 設立メンバ 3週連続DDD 「ドメイン駆動設計」の要点と実践ノウハウ
  2. 2. そんな人のために …そんな人のために … ・読み解くのが困難 ・実践でどう活用するか迷っている ・やってみたがうまくいかない
  3. 3. アジェンダ • 戦略的な取り組みの事例 • 基本がたいせつ • 第14章 モデルの整合性を維持する • 第15章 蒸留 • 第16章 大規模な構造 • 第17章 戦略をまとめ上げる • 3週連続DDDのまとめ
  4. 4. 第4部 戦略的設計
  5. 5. 3社での取り組みの事例
  6. 6. • 企業の人材採用/雇用支援システム • 汎用プロダクトかつ個社対応 – 採用雇用は経営戦略であり企業の独自性が強い • 会社としての成長とシステムの成長 創業から10年のおつきあい パートアルバイト領域 パートアルバイト領域 キャリア採用 アパレル特化求人サイト 個社対応 顧客:数百社 挑戦テーマ ・深いモデル ・しなやかな設計 ・成長を続ける全体
  7. 7. SBヒューマンキャピタル • ソフトバンクグループの人材系サービス会社 • 切り口の異なる複数サービス – 基本は「求人」「職務経歴」「応募」で同じだが… • 他社サービスを含めさまざまな連携 10年来のおつきあい モデルの整合性の 挑戦ネタの宝庫
  8. 8. • インターネットサービスプロバイダ • 基幹システム – レガシー – 顧客、契約、請求、物流、サポート、… – キャリア連携/販売チャネル連携 • ドメイン駆動設計で「太陽系戦略」に取組中 現場での支援活動2年 継続中 ISP事業の基幹システムでの挑戦 現場の問題意識と意欲的な活動 勉強になる
  9. 9. 取り組みの現実 • HRソリューションズ – システムも事業も実業務にも精通した一人の優秀な 技術者と、案件ごとに、改善の取り組み – 経営が変化とスピードを重視し実践している • システムづくりと運用が超たいへん • SBヒューマンキャピタル – 短期的な課題、個別の課題解決に忙殺されがち – 現場レベルでの戦略的な取り組み意識の向上から • ビッグローブ – 戦略的な取り組みの意欲と実践 – 時間がかかるだろうが一歩一歩前進中
  10. 10. 戦略的に取り組む • 時間がかかる • 関係者が多い • 障害が多い • すぐには見えない効果 • それでも取り組む動機 • 一歩一歩進む • 基本に忠実に ものづくり屋の本能 良いもの、役に立つものをつくりたい ビジネス上の期待に応える
  11. 11. 誰がやるのか • 意思決定と行動 – 開発チーム/現場の技術者 – 複数の開発チーム • どうやって – 言葉を使った意図の伝達 – さまざまな力関係とトレードオフの判断 • そのための膨大な知識の理解と整理 – 戦略を「コード」で表現する
  12. 12. 戦略的に取り組む場合こそ 基本がたいせつ
  13. 13. 「基本」を戦略的に実践する • 「オブジェクト指向」を戦略的に • 「エクストリームプログラミング」を戦略的に • 第1部の「三原則」を戦略的に • 第2部の「基本スキル」を戦略的に • 第3部の「深いモデルの探求」を戦略的に
  14. 14. 「戦略的」 •広い視野で •多くの関係者で •時間をかけて
  15. 15. 「ドメイン駆動設計」の基本 この二つを組み合わせたソフトウェア開発。 その成功と失敗の経験から学んだことをまと めたものが「ドメイン駆動設計」。 オブジェクト指向 エクストリームプログラミング
  16. 16. オブジェクト指向と「変更容易性」 • 抽象データ型/段階的抽象化 – プログラムを人間の発想に近づけると扱いやすい • モジュラープログラミング – 独立性の高い部品に分けると扱いやすい • メッセージング – 部品の組合せ型が柔軟だと扱いやすい どのパラダイムにも共通する設計の考え方 ドメイン層のコードは、たぶん似たものになる
  17. 17. LocalDate 日付を汎用的に扱う手段 Java APIのレイヤ int year short month short day LocalDateの内部 Java言語仕様のレイヤ if( day > 31 ) … DateOfBirth 「誕生日」に用途を限定した独自定義クラス 「ドメイン層」の一級市民(ドメインオブジェクト) 人間の発想 コンピュータの 仕組み 抽象データ型/段階的な抽象化 コードを人間の発想に近づける Boolean 今月が誕生月() Days 誕生日まであと何日() plusDays() plusMonths()
  18. 18. 「モジュール化」と「メッセージング」 受付役 仲介役 回答役 経路情報 専門家 判定役 おーい 手伝って 後は まかせた おーい 考えて おーい 教えて 教えて 最短経路は… 独立性の高い部品 独立性の高い部品 独立性の高い部品 独立性の高い部品 独立性の高い部品 人間の営みと同じ仕組み 必要に応じて最適チームを結成
  19. 19. 「適応型」のソフトウェア開発 開発の スタイル 方法論 ソフトウェアの 最終形(着地点) 開発サイクル 予測型 ウォータ フォール 事前に定義 厳密に定義 固定 分析/設計/製造 反復・ 漸進型 RUP それなりに定義 反復ごとに精緻化 方向付/推敲/作成/移行 各フェーズで分析/設計/製造を、 N回「反復」する 適応型 XP スクラム ざっくりと定義 日々更新 日、週、春夏秋冬 (人間の生活リズム)
  20. 20. ソフトウェアの開発スタイル • 「変更」との戦いの歴史 – 変更のコストとの戦い – 変更のリスクとの戦い • 「エクストリームプログラミング」は、積極的に 「変化を目指す」開発スタイル 変更を 管理する 変更を 受入れる 変化を 目指す 予測型 反復・漸進型 適応型
  21. 21. 変化を目指す開発チーム • コミュニケーション – 言葉を使って意図を伝える • シンプリシティ – 複雑になるほど変化が難しくなることを知っている • フィードバック – 経験/実験にもとづき進むべき道を探す • 勇気 – 行動する勇気、耐える勇気 • リスペクト – お互いの考えと行動に関心を持ち、かつ、尊重する
  22. 22. 戦略的に取り組む • 「オブジェクト指向」の変更容易性 をより広く、より長期に • 「エクストリームプログラミング」の 適応型の開発をより広く、より長 期に 第4部 戦略的設計に取組みながら、ここの理解と実践力を鍛える
  23. 23. 第1部の3原則を 戦略的に実践する
  24. 24. より広く、より長期に 第2章 言葉を使った意図の伝達 第1章 ドメインの知識をかみ砕く 第3章 モデルと実装を結びつける ドメイン モデル ドメインの 膨大な情報を かみ砕き、蒸留して 重要な関心事を 鋭く説明する 選び抜かれた ドメインの重要な関心事を コードで表現する 会話を繰り返して 「要約」を改善する (重要点を明確にする) 「重要な語彙」をメンバーで 合意する/共有する
  25. 25. 活動の目的/背景 ドメインとソフトウェア 利用する人たちの 活動と関心事 ソフトウェア 戦略的設計では、視野をさらに広げる 3社はここがある程度できている
  26. 26. モデル • 膨大な知識を「要約」した シンプルでわかりやすい説明 • モデリングのスキル=「要約力」 –重要な要素を発見する力 –本質的でないものを削る力 –厳密に組み立てる力 本質的でないものを削る力がほんとうに重要 議論と行動が迷走しないために
  27. 27. 3つの原則を戦略的に • 第1章 知識をかみ砕く – 戦略的な意思決定をし、適切に行動するためには、 膨大な知識が必要 • 第2章 言葉を使う – 戦略的な意思決定も、開発チームのメンバーの 「言葉」を使ったコミュニケーションが基本 • 第3章 モデルと実装を結びつける – 戦略も、コードで表現する
  28. 28. 第2部の基本スキルを 戦略的に実践する
  29. 29. ドメイン層に集中する システム間連携も ここに焦点をあてる。 難しい…
  30. 30. 関心事を「抽出」し 関係に注目する ひとつに見える対象から、 関心事を抽出する。 いろいろな可能性が広がる。 一枚岩では動きがとれない。
  31. 31. 第2部を広い範囲で長期的に • 利用する人たちの関心事を隔離する – 「ドメイン層」 • 利用する人たちの関心事を「抽出」し「コード」 で表現する – 「ドメインオブジェクト」 • 関心事の「モデル」(要約)に集中する – 機能視点で駆動しない – データベース視点で駆動しない – 画面視点で駆動しない 機能/データベース/画面の中核にある「関心事のモデル」を探す
  32. 32. 第3部を 戦略的に実践する
  33. 33. 深い洞察に向かうリファクタリング • 「深いモデル」を探求する • 「しなやかな設計」を工夫する • 焦点を絞る • より広い範囲で • より長期的に
  34. 34. 概念を掘り出す努力していますか? • 言葉に耳を傾ける • ぎこちなさを精査する • 矛盾について熟考する • 文献を読む • 何度でも挑戦する ドメイン駆動設計の実践のキモ これを広い視野で、より複雑な問題を対象に 長期的に実践するのが戦略的な設計の基本 9章を読みながら、個人やチームで振り返りを 多くのメンバー/チームの 日常の習慣になってくると その集積が戦略的に効いてくる
  35. 35. 深いモデル/しなやかな設計 • ドメイン層のごく一部での取り組み • ドメイン層全体に波及する – 業務知識を要約し鋭く説明できる力 – ソフトウェアの変更容易性を向上するテクニック • システム全体に波及する – プレゼンテーション層/アプリケーション層/データソース層 • 連携するシステム全てに波及する チームの全員の考え方と行動に波及する すべての関係者の考え方と行動に波及する
  36. 36. 第4部 戦略的な設計
  37. 37. 第14章 モデルの整合性 第15章 蒸留 第16章 大規模な構造 第17章 戦略をまとめ上げる
  38. 38. 第14章 モデルの整合性を維持する
  39. 39. 第14章の概要 • 境界づけられたコンテキスト • 継続的な統合 • コンテキストマップ • 境界づけられたコンテキスト間の関係 • 象のモデルを統一する • モデルコンテキスト戦略を選択する • 関係を変更していく
  40. 40. 境界づけられたコンテキスト 大きな部品を特定する • 一つのモデルとして独立していそうな範囲 – 開発チーム – 運用チーム – コードベース – データベーススキーマ … • ひとつのモデルが適用できる範囲の制限 • モデルの一貫性を保つ努力をする範囲の限定 • チームの「言葉」の通用する範囲に注目する これらが分かれているが、1つのモデルということはない ひとつの範囲に複数のモデルが生まれてしまうことはある
  41. 41. ひとつのコンテキスト内で 継続的な統合をする • チーム内(境界づけられたコンテキスト内)の 「一貫性」を維持する • 「概念」は、別々の人の頭の中でばらばらに進 化をはじめることに、いつも注意する • コードの統合に成功しても、「理解」が統合でき ていないリスクを気に掛ける • 複数のコンテキスト間の関係を扱いやすくする ための前提
  42. 42. コンテキストマップ コンテキスト コンテキスト コンテキスト モデル モデル モデル 「ドメイン層」の「モデル」間の関係 現実がどうなっているかを知る 関係者でスケッチしてみると 「気づき」が多く、非常に効果的 季節単位くらいに繰り返したい
  43. 43. コンテキスト間の関係 別々の道 チームのコミュニケーションの意欲と能力 関 連 す る シ ス テ ム に 対 す る 制 御 腐敗防止層 順応者 顧客/供給者 チーム 公開ホスト サービス 共有カーネル 単一の 境界づけられた コンテキスト 共同経営 現実を直視 なぜそうなっているかを理解する
  44. 44. 第14章の要点 • 現実を直視する – 関係者で共通の理解に – 背景や歴史まで視野を広げて – ある種の「美しさ」 • 開発チームによる意思決定と行動 – チーム内 – チーム間 • 統合による利益と調整コストのトレードオフ
  45. 45. 密接な関係を実現する • 複数のコンテキスト(チーム)を単一のコンテキ スト(チーム)に統合にする • 共同経営 • 共有カーネル(複数チームで共同開発) 密接な関係のメリット 密接な関係のコスト 短期・長期 局所・全体
  46. 46. 明確な関係を打ち立てる • 顧客/供給者のチーム • 公開ホストサービス • 公表された言語 関係を確立するメリット 関係を維持するコスト 短期・長期 局所・全体 コミュニケーションしながら どこかに合わせる
  47. 47. 独立した別のチーム • 別々の道 • 順応者 • 腐敗防止層 独立しているメリット 独立により発生するコスト 短期・長期 局所・全体
  48. 48. コンテキスト間の関係の 意思決定 「意思決定」とは、コードでどう書くかを決めること
  49. 49. 戦略を選択する時の考えどころ • チームでの意思決定と、より上層での意思決定 • コンテキストに自らの身を置く • 境界を変換する • 変更できないものを受入れる • 外部システムとの関係 • 設計中のシステム • 別のモデルの特殊な要求を満たす • デプロイ • トレードオフ • すでにプロジェクトが進行中の場合 「現実の直視」 「トレードオフ」 「実践的な判断」 熟読すべし 関係者で議論すべし page.391~398
  50. 50. 変換(関係を変えていく) • コンテキストをマージする – 別々の道 ⇒ 共有カーネル – 共有カーネル ⇒ 継続的な統合 • レガシーシステムを段階的に廃止する • 公開ホストサービス ⇒ 公表された言語 「現実の直視」 「トレードオフ」 「実践的な判断」 熟読すべし 関係者で議論すべし page.398~404
  51. 51. 第14章 まとめ • ひとつのコンテキスト内部のモデルの一貫性を 維持する • 現実のコンテキストマップを作る • コンテキスト間の選択肢を共通理解にする • 現実を直視する • トレードオフを考える • 関係者で活発に意見交換する 関係者の活発な意見交換がすべての戦略的設計の前提 「意思決定」を、必ず「コード」で表現すること
  52. 52. 第15章 蒸留
  53. 53. 第15章の概要 • コアドメイン • 蒸留の拡大 • 汎用サブドメイン • ドメインビジョン声明文 • 強調されたコア • 凝集されたメカニズム • 蒸留して宣言スタイルにする • 隔離したコア • 抽象化されたコア • 深いモデルの蒸留 • リファクタリングの対象を選ぶ
  54. 54. コアドメイン 選択と集中
  55. 55. 中核中の中核を見究める • 中心になる問題に集中し、枝葉末節の海でおぼ れないようにする – 「ドメインモデル」自体が、重要な関心事のかたまり – 「ドメインモデル」が複雑になってきた時に、さらに、そ の「中核」部分を見究める活動 – 高度な「要約力」 – すこしずつ、実験とフィードバックを繰り返しながら「コ アドメイン」を識別していく • ビジネスへの影響の大きさ/ソフトウェアの価値 – 「第1章 知識をかみ砕く」を高度に実践する
  56. 56. 「中核」の探し方 • 「かたまり」を「抽出」する • それぞれの「かたまり」の「意図」を明確にする
  57. 57. かたまりを「抽出」する • 「汎用サブドメイン」 – 独立性が高く、一般的な業務知識などをたよりに 発見できる「かたまり」 • 「凝集されたメカニズム」 – 技術的な関心事の隠ぺいを追求することで発見 できる「かたまり」 – 「意図の明白なインタフェース」のみ公開する
  58. 58. 「かたまり」の「意図」を明確に • 名前 • 「かたまり」間の依存関係 • 「言葉」を使って「名前」と「関係」の検証と改 良を続ける – AはBを使う – AはBに依存する – AはBを詳細化する … 「関係」をもっと知識豊富な言葉に
  59. 59. 「コアドメイン」の具体化 4つの段階 • ドメインビジョン声明文 • 強調されたコア • 隔離されたコア • 抽象化されたコア これが書けない 語れない
  60. 60. 「ドメインビジョン声明文」 • 言葉を使って「コアドメイン」を表現してみる • 費用対効果が高い – 簡単に取り掛かれる – 簡単に複数案を作れる – 簡単に変更できる • チームが根本概念を共有する効果 • 正しく表現する – 語尾をあいまいにしない – だらだら語らない – 「あれ」「これ」「それ」を使わない – 「カタカナ言葉」を使わない
  61. 61. 「強調されたコア」 • 実装は変更しない • 既存の「モデル」で重要な点を強調 – 本質的なオブジェクトを書きだしたり要約図を描い てみる – ドキュメントがあれば、付箋やマーキングで強調し てみる • ラフスケッチと「意見交換」 – 強調した点を「正しく」表現してみる • チームで「主要な関心事」を共有する手段
  62. 62. 「隔離されたコア」 • コードを実際に変える • 重要な要素を、特定のモジュールに集める • リファクタリング – モジュール構成 – モジュール名 – クラス名 – メソッド名/引数の型/返す型 … • 深いモデルをコードに反映 • しなやかな設計にして変更に機敏に対応
  63. 63. 「抽象化されたコア」 • 根本的な概念を、クラスやインタフェース宣言 に「抽出」する • 他の詳細は、この抽象化されたコアに依存す るように設計する • 根本の概念は安定しているが、詳細の変更が 頻繁に発生する時に、効果を発揮する 「深いモデル」の探求の帰結 「しなやかな設計」の追求の帰結
  64. 64. 第15章 まとめ • 「中核の関心事」を、「コード」を書く人間が的 確に理解する効果 • 「中核」の関心事を、「コード」で表現する威力 • 少しずつ地道な改善活動 – 「チーム」で続ける – 大勢で、長期的に – 協力のための手段「言葉」 – 「第3部 深い洞察に向かうリファクタリング」の高 度な実践
  65. 65. 第16章 大規模な構造
  66. 66. 第16章の概要 • 進化する秩序 • システムのメタファ • 責務のレイヤ • 知識レベル • 着脱可能コンポーネントフレームワーク • 構造による制約にどの程度厳しくすべきか • ふさわしい構造への「リファクタリング」
  67. 67. 主題:「森を見る」力をつける • コードに責任を持つ開発者たちが、「全体を俯 瞰」し理解する効果 • 大きく複雑なシステムの「秩序」を少しずつ改 善していくための手掛りの発見 • 関係者が全体の構造を理解し議論するための 「枠組み」を手に入れる効果
  68. 68. 「森」を少しずつ成長させていく • 「秩序」を改善する • 「全体」を成長させる • 時間をかけて • 何世代にもわたって • 「有機的な秩序」を壊さないように
  69. 69. メタファー • チーム内の共通理解に強力な武器になること がある • 「わかったつもり」で、実際には異なる理解に なる危険性も高い • 「カタカナ」は厳禁 • 「キャッチフレーズ」は厳禁 • いつでも、だれでも同じ言い回しになる「言葉」 であること
  70. 70. 責務のレイヤ • モジュール(独立性の高い部品)の抽出が前提 • モジュール間の「依存関係」に注目して整理する • 候補 – 意思決定 – ポリシー – 確約(コミットメント) – 業務(オペレーション/トランザクション) – 潜在能力(リソース) • 始めは、上下2層にわけることから – 層が多いことが役に立つわけではない • 参照の方向性を一方向に限定する実験は効果的 最初は不自然な設計に見えるが、ブレークスルーのきっかになることがある
  71. 71. 役に立つ着眼点 • 時間軸での依存関係 – 先に存在すべきオブジェクト • 変更の理由/変化のサイクル – 頻繁で継続的/短い イベント系 – 時々/ゆっくり リソース系 – ほぼ固定 制度 • 「責任分界点」とそれぞれの「責任」 – 契約/利用規約 – 職務分掌規程 • 「依頼役」と「サービス提供役」 比較的、体系的に学べる
  72. 72. 「知識レベル」 • 判断ロジックがごちゃごちゃしたり、置き場所に 迷う時 • 簡単な実験 – XxxType と Xxx に分けてみる – 例:従業員タイプと従業員 • 「レイヤ構造」ではない – 参照を一方向に限定する必要はない
  73. 73. 16章のパターンへのコメント • メタファ – わかりやすいが危険 • 責務のレイヤ – 分析により比較的、論理的に発見できる – データモデリングなどの考え方と手法も参考になる • 知識レベル – 判断ロジックがごちゃごちゃしたり、置き場所に迷う時 • 着脱可能なコンポーネントフレームワーク – ここまで熟成している間に環境がかわってしまう? – 適応型の開発スタイルでは、目的地ではなく結果
  74. 74. ふさわしい構造へのリファクタリング • ミニマリズム – いちどに大きく取り組まない • コミュニケーションと自己規律 – ドキュメントでは一貫性は維持できない – チームの通常の会話では、全体の構造を共有できな い(視野の経験の差が大きい) – 「戦略」を「言葉」と「コード」で表現する • 繰り返し形を変えることでしなやかな設計になる • 継続的な蒸留(補助的な構造の削除)による負 荷の軽減 設計の改善
  75. 75. 第16章のまとめ • モデルが大きく複雑になってきたときの整理の 考え方とやり方 • ビジネスモデリングやアナリシスパターンの文 献から学べることも多い • 蒸留(深いモデルの探求)とリファクタリング(し なやかな設計の追求)を、広い範囲で、長期 的に取り組むための手段
  76. 76. 第17章 戦略をまとめ上げる
  77. 77. 第17章の概要 • 「大規模な構造」と「境界づけられたコンテキス ト」を組み合わせる • 「大規模な構造」と「蒸留を組み合わせる」 • まず評価する • 誰が戦略を決定するのか • 戦略的設計の「意思決定」を行うために欠か せない6つのこと
  78. 78. 戦略的な設計に取り組むためには まず現状を正しく把握する • コンテキストマップを描くこと – あいまいな点や怪しいところを発見する • 「言葉」の使われ方を評価する • 何が重要であるかの理解度 • モデル駆動設計に向いた技術を使っているか • 開発者の技術スキル • 開発者のドメインへの「関心」の度合い さまざまな厳しい現実と誠実に向き合う
  79. 79. 誰が戦略を策定するのか • エクストリームプログラミングの「アーキテクト」 – 通常はプログラムタスクを担当する開発者 • 「ドメイン層」を開発するチームから、システム の全体的な構造が現れる – 全体的な構造も「ドメインモデル」が駆動する • 「アプリケーション開発チーム」に貢献する 「アーキテクチャチーム」 最初から優れたアーキテクトはいない 現場で、実践の中で才能を見出し、育てて行く。 (自分も含めて)
  80. 80. 戦略設計上の意思決定 かかせない6つのこと • 意思決定はチーム全体に伝える • 意思決定のプロセスにフィードバックを組み込む • 計画は変化し進化を続ける • アーキテクチャチームが優秀な人材を吸い上げて はいけない • ミニマリズムと謙虚さ • オブジェクトはスペシャリスト、開発者はジェネラリ スト
  81. 81. 第17章へのコメント • コードを変更する人間が「戦略」を理解し、実行に移 すことがもっとも効果的 • 「戦略」も「言葉」による意図の伝達と実験が基本 – 多くの人たちが長期的に取り組むための武器 • 変化に対応し、少しずつ成長を続ける全体 – 「適応型」の開発スタイル – 「戦略」こそ「日々」の変化の積み重ね – 進化を続ける「有機的な秩序」 – 「まちづくりの新しい理論」
  82. 82. 第3週「戦略的な設計」のまとめ • 基本たいせつ – オブジェクト指向 エクストリームプログラミング – 第1部の3原則(知識・言葉・コード) – 第2部のモデルと実装を結びつける基本スキル – 第3部の深いモデルの探求としなやか設計の追求 • 第14章 境界と関係を明確にする • 第15章 「中核」に焦点をあてる • 第16章 大きな単位のモジュール化/依存関係 • 第17章 進化する秩序、成長する全体
  83. 83. 3週連続DDD まとめ
  84. 84. 3週連続DDD • 第1週 ドメイン駆動設計の基本を理解する • 第2週 深いモデルの探求 • 第3週 戦略的に取り組む
  85. 85. 「ドメイン駆動設計」とは 厳しい現実の中で、ソフトウェア設計を習得しよ うと奮闘してきた技術者の物語。 不完全な状況の中で、抽象的な設計原則を、 現実のソフトウェアに適用するための助言。 「日本語版への序文」 by エリック・エヴァンス エヴァンスは、ソフトウェア開発の成功も失敗も味わってきた。 この本は、エヴァンスが成功と失敗の両方から学んだ教訓を伝 えている。 「序文」 by マーチン・ファウラー
  86. 86. 厳しい現実だらけの現場で より良いソフトウェアを作るために 「実践的な設計」の勉強を続けよう
  87. 87. • どんな状況でも改善できる • どんなときでも「あなた」から改善を始められる • どんなときでも「今日」から改善を始められる エクストリームプログラミングの 「はじめに」に記された ケント・ベックのメッセージ
  88. 88. ありがとうございました
  89. 89. 【広告】DDDの3原則を体験的に学ぶ • 【DDD Alliance】 第2回 実践的ドメイン駆動設計ワークショップ • http://ddd-alliance0002.peatix.com • 9月26日(土)と10月3日(土)の2日コース • 有償(1万5千円 税抜) • 内容 – 「要約力」 – 「ドメインの創造的な学び方」 – 「言葉」を使ったモデリングと設計の体験学習

×