1回じゃ話しきらないので3週に分けて。
DDD Allianceのみなさん、増田さん、ありがとうございます。
すらいど
http://www.slideshare.net/masuda220/ddd-52339527
- 読み解くのがこんなん
- 実践でどう活用するのか迷ってる
- うまくいかない
→ さらなる成長のため！！！
やってみて
難しい！
振り返ると、最初の頃は勘違いしていたな、と気付く。
一般的な用語を使っているけど、エヴァンスは違う意味で言っているのでは。
ドメイン駆動設計とは
日本語版の序文参照。
もう一度読み返すと気付くことがあるから振り返ってみよう。
共感を持てることが多い。
エヴァンスの取り組み
- オブジェクト指向
- エクストリームプログラミング
この2点がキー。
これを経験した人が想定読者。
当時はOOP、XP知らなかったことが障害になっていた。
勉強になった本
増田さん、エクストリームプログラミング勉強中。
- リファクタリング
- 実践パターン
- エンタープライズアーキテクチャパターン
- エクストリームプログラミング
- Wabi Sabiを読み解く
- XPやりたいならぜひ！
- まちづくりの新しい理論
- アレグザンダーの考え方の影響を受けてる。
適応型のソフトウェア開発
2つに共通するのは成長と変化を続ける開発
車の両輪
- オブジェクト指向 → 変更容易性
- エクストリームプログラミング → 変化適応性
アジャイルは適応型。反復型ぽく見えるけど違う。
適応型。
目的地は決まってるけど、どの道を行くか・どれくらいのスピードを出すかが考えられる。
XP(適応型)はドライブで例えるとわかりやすい。
人間らしいリズムにした方がパワーが出るよね、ってのが基本。
日々変化し成長する
朝方向付けて遂行して、午後作って、夕方デプロイする。
次の日に方向性間違ってなかったね、渡フィードバックを受け取る。
一日一日で実際にはそんな方向転換はしないけど、なんか機能と違うことはあるよね。
YAXP(Yet Another XP)
要求が曖昧。
なるはや
そんな状況でいかにうまくやるかがXPの価値。
変更容易性
抽象データ型・段階的な抽象化
→人間の発想に近づける
モジュラープログラミング
→部品にする。
メッセージング
→部品の組み合わせ
抽象データ型で人間の発想に近づける
int → LocalDate → DateOfBirth
概念を抽象的なデータ型で表す。
人間の関心のあるクラスだけにフォーカスしていく。
OO+XP=DDD?
DDDが協調する点
- ドメインに焦点を当てる
- モデルとコードの歩調を合わせて成長させる
- 言葉を使ってチームでモデル・設計を改良する
DDD理解の鍵
- 焦点を当てるとはどういうことか？
- 歩調を合わせるとは、具体的にどうするのか？
ドキュメントとは過去のものなんで、今のものを表現するのは言葉だよ、と。
第1部 ドメインモデルを機能させる
- 知識を噛み砕く
- コミュニケーションと言葉の使用
- モデルと実装を結びつける
この３つ。
これらを自分たちなりに実践するだけでも価値が出てくるはず。
ドメインとは
コンピュータとの接点ではなく、何をしたいのか、何をするためにソフトウェアを使用するのかと言うところに関心毎がある。
そこに焦点を当てて理解することが大事。
ドメインではないこと
- ソフトウェアを作る活動
- コンピュータの仕組みや挙動
- 仕様書・機能一覧…
開発者は↑を見がち。
ここに深いいみぞがある。
これらは切り取ったものでしかない。
活動の文脈
受注登録→開発者の見る受注登録は１つの機能。
利用者の受注登録は月初、月末…など色んなものがある。
活動と関心事を理解することが大事。
これを理解して作るかどうかで差が出てくる
モデリング
モデルは実体ではない
要点はなんなのか
これを探すこと
モデ力＝要約力
本質的でないものを削る力
重要なものを出すのは簡単。
本質的かどうかを理解できるようにするために知識を得る。
だからドメインエキスパートに聞くんだ。
ドメインエキスパートは感覚的にわかってても言語化できるのはまた別だから簡単に言ってはくれない。
でも間違ってる場合には言ってくれるはず。
突き詰めたスキルは「要約力」
ドメインモデル
関心事の本質を表現したもの
ドメインモデルを育てる
色んな記録を使って過程を書いているのが第１章
ユビキタス言語
雑談でもドメインの言葉が出てこないとダメ
言葉のやりとりは人間鍛えられてる！
それをそのままやればいい。
ドメインエキスパートと自分が使ってる言葉がなんか違うと感じたらツッコむ。
ユビキタス言語は育てに行くもの。
ユビキタス言語は500~1000とかになるはず。
声に出す
読み書きは辛い。
声に出す事が一番。
同じ言葉を使ってるエリアこそが境界づけられたコンテキスト
言葉が違うところが境界だから一緒にできるわけじゃない。
継続的インテグレーション＝言葉のずれを統合していくためのもの。Jenkinsじゃないぞ。
言葉たいせつ
- 利用者の重要な関心事をよどみなく語り始める安心感
- 技術用語しか使わない恐怖感
業務の言葉を使ってればほしいものができるはずだ。
残った問題はあとからがんばればなんとかなるはず。
モデルと実装を結びつける
分析クラスと実装クラスを一致させる
手続き型プログラミングでできなくはないけど。。。
ラフスケッチ・コードを見せてお客さんに分かるのか？
→ わかる。
媒体の問題じゃない。
ドメインを理解してれば説明もできる。
ドメインモデルを画面でナビゲートする。
ドメインモデルと画面遷移は一致しているべきだ。
開発者はクラス図という感覚だけど、お客さんは画面遷移を見ているつもりになる。
実践的モデラ
これがあるからDDDっていいな、と思う。
コードを書かないやつがドメインの知識を理解しても良いものはできない。
第2部 モデル駆動設計の構成要素
モデルと実装の一致
第2部は基礎練習。
第2部の構成要素をどんな状況でも確実に使えることが第3部第4部を実践する土台になる。
レイヤ化アーキテクチャ
それなりの人なら表面的にはすぐできる。
ドメインの隔離
問題なのは簡単にコントローラとかに簡単にドメインロジックが染み出してしまう。
SQLのWhere句にしてしまうことはドメインロジックを持たせることになるからよくない。
形式的なもんじゃダメだ。
嗅覚研ぎ澄まして察知することが大事。
第5章の問題意識
モデルとコードの一致は難しい。
自然言語と人工言語のギャップが絶対にある。
モデルとコードを一致させやすいかどうか感覚的にわかるようになるというのが練習！！！
住所という概念が1つになってて意味のあるものになってる。
この感覚が大事。
エンティティ
AとBを人間はどう識別しているんだ？というところの関心だけにすることが大事。
とことんスリムにする。
一意識別とごっちゃにするのはやめる。
システム的にどう一意に識別するかはどうでも良い。
ドメイン層のサービス
可能な限り使わない方がいい。
危険なパターン。
とにかくドメインオブジェクトにする。
そうすると、ドメインオブジェクトにこの振る舞い持たせた方がイイよねって事に気づける。
ソフトウェアデザイン9月号見てね！
パッケージ
ドメイン層の構造を設計することの方がクラス名よりも重要。
効果が高い。
IDE使えば大丈夫だから積極的にやろう。
モデリングパラダイム
コードとモデルを一致させることは大変や
ドメインオブジェクトのライフサイクル
- 集約
- ファクトリ
- リポジトリ
第7章の構成
12ステップの流れを意識して読むと良い
最初の方にアプリケーション層をもってきてるのは、機能の面を隔離しろって事。
機能じゃなくて関心事に注目しろって事。
最後に
ケント・ベックのメッセージ
- どんな状況でも改善できる
- どんなときでもあなたから改善を始められる
- どんなときでも今日から改善を始められる
質問
- Q. クライアントサイドのバリデーションはDDD的にどうなのか？
- A. クライアントサイドでのバリデーションもサーバーサイドでのバリデーションもDBの制約に関してもそれぞれ必要。