DDD実践の現場に参加してきた
DDD(Domain Driven Design)実践の現場
- 2019/5/29@pixiv
ドメイン駆動設計の正しい歩き方
https://www.slideshare.net/masuda220/ss-148093123
- なぜDDDで作るのか?
Evansが求めた設計について
- 設計の一般論ではない
- ビジネスルールの複雑さがソフトウェアの複雑さの根本原因
ドメインロジック
- ビジネスルールをコードで表現したもの
- コアを整理していけば周辺が整理され、それが全体に波及して、シンプルなものが作れる
- 開発者がビジネス活動について継続的に学び続ける
ドメイン駆動設計を実践するための6つの問い
- ビジネスの活動を継続的に学んでいるか?
- コアドメインに集中しているか?
- 全てを同じにしようとする必要はない。コアに集中する。そこを徹底的に綺麗にする
- ビジネスを深く洞察しているか?
- ドメイン層を独立させているか?
- ロジックを画面やテーブル構造と一緒にする必要はない
- モデルと実装を密に結合しているか?
- 実装に役立たないモデリングはどこか間違っている可能性がある
- システム間の秩序の改善を続けているか?
- もっと良い方法がないかを検討し改善し続ける。もっとシンプルなIFに出来ないか、など
ドメインロジックを独立させる
- まず料金を計算するのにはどう(メモリ上で)表現いいのかを考える -> 画面やDBのことは一旦忘れる
- 料金計算ロジックを独立させる
- モデリング
- ルール、攻勢要素とその関係を自然言語やすい式などで表せるようにする
- モデリングは仮説を立てる<->コードで表現するを行き来して作り上げる
コアドメインに集中する
- 中核となるルールは、繰り返し出てくる部分
- どこを軸にとるか?
- どこを軸にしてコードを書くとシンプルになるか? => 抜粋版みたいなコードを書いてモデリングの妥当性を検証する
- 歯抜けの仕様書を渡された時に、歯抜けの部分がさぐり当てられるか? -> ビジネスに対して深く理解していないとこれが出来ない
DDDを現場に導入する
- 体験的に習得する -> ハンズオン、OJTなど
- エヴァンス本をちゃんと読む
- 28ページの抜粋版を読む
- 要点を重点的に読む
- 9,10章あたりはビジネスを深く洞察する、ということがどういうことなのかに触れている
DDDをできるようになるには?
- 増田さんの本:現場で役立つシステム設計の原則
- isolating-the-domain -> サンプルコード
- jig -> 設計可視化ツール
- オブジェクト指向設計 -> ドメイン駆動設計本格入門 スライド => VOなどの具体的な設計
この辺りを理解すればEvans本の想定読者の要件をクリアできるはず
質問にあがっていたこと
- ドメインエキスパートの説明がうまくない場合は?
- 期待しない・・自分の質問したいことの具体例を持って質問する。わざと間違えた質問をぶつけて話してもらうのもあり
- ビジネスルールの複雑さに立ち向かう -> ここにビジネスルールが複雑になる原因などについて書かれている
モデル駆動型開発によるビジネスをソフトウェアに落し込む1つのやり方
- 複雑なものをシンプルに
- ユビキタス言語はチームやドメインエキスパートとの対話で生み出す
- 対話をするためには一般業務知識や専門用語の理解なども必要
- ユビキタス言語を値オブジェクト(or エンティティ)で表す
- ドメインモデル貧血症
- ビジネスルールがほとんどなくデータの入れ物のようになってしまっているドメインモデル
まとめなど
- 最近、進化的アーキテクチャの本を読んでいたこともあり、ドメインを育てる、進化させるということがまさに進化的アーキテクチャを実践する方法の1つになるんだということを感じた
- 今までスライドや本でしか増田さんの話を聞いたことがなかったが、現場での説明や小話を交えてで得られる情報は貴重だなと改めて感じた
- システム間の秩序の改善の話については、個人的には頭をガンと打たれたくらいの衝撃だった。外部とのやりとりのインターフェースがイマイチなことのせいにしてあきらめている自分がいたが、自分でできることはなにか、ここから改善できることはないのかを常に考え改善していくというマインドを持ってことに当たるということが欠けていたなと気付かされた