今週も来ました。
2回目です。
おさらい
考え方と背景
基本中の基本。
オブジェクト指向とエクストリームプログラミング
これらの経験が大変役に立つはず。
DDDはエヴァンスの経験談。
役に立つソフトウェアを作りたいならLocalDateクラスではなくDateOfBirthを作ろう（例）
適応型＝ゴールはなんとなく決めるけど、本当にどうなるかは分からん。それを日々反映していくもの。
人間のリズム
これが大事。効率が良い。
エヴァンス極端な事言ってるような気がする。
第2部に書いてることやっても実感としてDDDが言わんとしてることは出てこない。
あくまで土台。
そこに3部の内容が入ることでパンチがきいてくる。
技術者がドメインの知識を求めていくこと。
鋭く説明する。
ドメインモデルは実際のコードの一部でしかない。
それくらいドメインモデルは要約されていなければならない。
利用する人達の活動と関心事だけにフォーカスするんじゃなくて、活動の目的・背景にも目を向ける。
膨大な知識を要約したシンプルでわかりやすい説明
ドメインの知識を並び立てることじゃない。
本質的ではないものを削る力。
厳密に組み立てる力→論理的にできてないとどっちみちコードにしたときに破綻する。
ドキュメント書くヒマあったら聞けばよくね
話して伝わるならそれでいい。
残しておかないといけないものはドキュメントに。
基本はコードに残ってるんだからいらないだろう。
厳選された情報だけをドキュメントにすればいい。
ユビキタス≠Common
チームの言葉を作っていこうという姿勢
ドメインを理解してるエンジニアとドメインに興味を持ってないエンジニアなら少しくらいプログラミングスキルの差があっても前者の方がよほどいい。
最初にキレイなアーキテクチャとフレームワークを決めることはDDD的に意味はない。
アプリケーション層にif文が入り込んだりしてドメインが染み出してくる。
発想の転換
第2部がわかんなかったらすっ飛ばして第3部読んでもいい。
作ったら終わりで知らない、じゃない。
言ったり来たりが大事。
深いモデルの探求
第1部、2部を見た自分たちの実践度合いを確認するために第3部を見ると良いかも知れない。
実際に役に立つモデルを探す
第3部はつかみ所のない部！
導入
ドメイン層と 設計と実装の議論
文中に技術的な用語が出てきても疑って欲しい。
技術論一般の事じゃなくてドメイン層で語っていることなはず。
リファクタリング
一般的な技術書で語られるリファクタリングは一般的などのドメインでも利用できる技術的な視点でのリファクタリング。
DDD本はドメイン層の設計に視点を置いている。
- 重複したコード
- 1つの関心事が色んなところに出てくるのがおかしい
- 長いメソッド
- 巨大なクラス
- 概念が埋もれてしまっている
- パラメータが多い
- 多用途に使おうとしてる
大きいから「分割」するんじゃない、その中に価値のあるものが埋まってるから「抽出」する！
深いモデル
これに至るためのことが第3部には書いてある。
ドメインの表面的な側面を捨てる
本の中のパターンや具体例ではあんまり出てこないので注意。
気にとめておきましょう。
モデリングのキモ。
第3部に書かれてるパターンを全てに適用したらムダ。
深いモデルを探求するためにはしなやかなコードが必要。
言葉を使った実験について来れなくなってしまう。
普通にオブジェクト指向の考え方を勉強してれば第3部に書かれていることはできるレベルの話。
第8章ブレークスルーを読む
普段やってて「あ、そっか」みたいなのがあるよねって話やで。
ブレークスルーが起きたときに冷静にどうするかを考えることが大事。
パッション。
第9章 暗黙的な概念を明示的にする
概念を掘り出す。
何度も何度もやる。
現実は厳しいけど、この概念の掘り出しをやることが意味のあること。
難しいけど取り組む価値がある。
概念を掘り出す努力していますか
- 言葉に耳を傾ける
- ドメインエキスパートとの会話で違和感を感じる
- 一瞬の間とか
- 要は空気
- こういうのに鈍感になってたら概念なんて見つけられない
- ぎこちなさを精査する
- 概念が書けてるとコードが複雑になる
- ドメインの言葉で語って、その時言った言葉がメソッドになってないとおかしい
- 概念を言葉にできているか
- ドメインの言葉以外で説明が始まったら止める
- 矛盾について塾講する
- 何か道の概念があるんじゃないかと考える
- 全部できるわけじゃないけど、少しくらいは考える
- これを習慣にする
- それを記憶しておく
- あとで気付いたときに記憶と結びついて
- 文献を読む
- 新人教育用のテキストとか読むといい！
- 全部勉強するのは難しい
- 自分の知らないことを知っている人を人脈として持っておくといい
- ビジネス文書の書き方入門みたいなのを一度はかじっておこう
- 文献とか全部を見る必要はない
- 目次とか概要説明とか基本的な概念を押さえればOK
- 何度でも挑戦する
- 手がかりは些細なこと
- 頻繁にやることが大事
- 習慣にする
- 第3部を貫いているメッセージ
9章の補足
- 制約
- 汎用性を重視しているからこれに気持ち悪いと思うことが大事だ
- この感覚をチームで磨く
- ドメイン層を磨くには良いチームになる
- プロセス
- オブジェクトでは時系列を表すのはむずい
- 最近だとReactive、イベントストリームが出てきたから使える
- これは勉強する価値が高い
- ドメインを表現する道具としてイベントストリームやReactiveを使うのは挑戦的
- 仕様
- DDD書いたときよりは今はもっといいものがあるかもしれない
第10章 しなやかな設計
トライアルしやすくなるよって話
ValueObjectを使おう
Immutable
制約を表明によって実装する
宣言的スタイルを意識し続ける！
- 技術者が利用する人達の関心事に集中するための工夫
- しなやかなほど実験がしやすい
第11章 分析パターンを適用する
ここの内容はいっぱい言いたいことがあるのでDDD Allianceのイベントとして必ずやります！
- 分析パターンを活用しろって話じゃない
- パターンは手がかりだ
第12章 デザインパターンをモデルに関係づける
デザインパターンはDDDでは重視してない
使うならドメインの観点で見直してね
第13章
リファクタリングのきっかけ
ブレークスルー気持ちいいけどそれでコードを全部やっちゃうのは危険
技術者のブレークスルーがドメインエキスパートが納得するか。
ドメインエキスパートとの感覚とずれていないかを確認する。
ミニマムにドメインエキスパートにフィードバックを得るならそこだけでもやる。
技術者だけで盛り上がらない。
第3部まとめ
- 深いモデル
- 主要な関心事の明快な表現
- 表面的な側面を捨て去る
- 深いモデルを目指したリファクタリング
- 言葉大事
- しなやかな設計を常に心がける
これらを地道にやったときにブレークスルーも起きる。
QA
- Q. Scalaで型というドメイン作ってくとDDDで言ってることに近くなる。ScalaとかHasckelとかの関数型言語でやるのはいいんじゃないですか？
- A. いいことだと思う。増田さんは関数型選ばない。なぜなら、関数型でやったらうまくいかなかった的な話がまだ少ないから。
成功談・失敗談出てくると嬉しい。