「エヴァンス本も読まずにドメイン駆動設計とは何事か?」 参加ノート
modeling-how-to-learn.connpass.com
ちょうどエヴァンス本を読んでる時にこちらのイベントを目にしたので申し込んでみました。 自分用ノートです。
イントロダクション
- 現場から学ぶモデル駆動設計 グループ
- https://modeling-how-to-learn.connpass.com/
- 実際に現場でやってどうだったかの肌感を共有する趣旨
- コメント欄 >「ドメインエキスパート」って「現場のエキスパート」だなとつい最近気づいた。「現場で役立つシステム設計」って「ドメイン駆動設計」ですねww
エヴァンス本から今学べること
www.slideshare.net
エヴァンス本をどういう本として読むか?
要求は定義されている前提で、ソフトウェアでどう設計していくかという本
- ビジネスやサービスの本ではない
システム設計ではなく、アプリケーション設計の本である
- どういう構成でシステムを組むか?ではなく、アプリケーションをどう設計するか、という内容
DB設計や画面設計については書かれてない
- SoRとSoE
既存の業務システムはSoR(System of Record)と言われ、正確に記録することを重視して設計されます。
一方、SoE(System of Engagement)とは、ユーザーとのつながりを重視して設計されるシステムを指します。
- https://www.cyzen.cloud/magazine/soe_sor
- SoRとSoE
設計の本で、要件定義・テスト・運用の話はしていない
- エンジニアとビジネスの関わり方、インタラクティブなあり方について書かれている
- 運用設計とはまた別
設計の本だけど、設計工程の本ではない
- コメント欄> Evans本として選択と集中があるってことですね。なんでも含めてしまうと焦点がぼやけてしまうんですよね。
エヴァンスのホームページでプロセスについてちょっと書かれている
何が書かれているのか?
- 考え方を示している
- 具体的な手法を取り扱わず普遍的な考え方を示すことで、陳腐化しない
- 考え方とは?
- ソフトウェアに業務知識を反映させよう
- そうすることで、柔軟に拡張したり変更したりできるようになる
- 「反映させる」とは?
- アプリケーションは分割と統合
- どう部品化するか?→業務モデルに合わせて部品化していこう
- アプリケーションは分割と統合
- 野球のミットがもし一枚板だったら硬いからボール取れない、軍手だと痛い
- コメント欄> 第3部の導入文にでてくるはなしですね
- コメント欄> リファクタリングしていくと、よく変わる部分と鉄板の部分が分かれてきて、使い込んだグローブみたいにソフトウェアがなってくよ、という感じの話ですよね。
- ソフトウェアに業務知識を反映させよう
- どう受け止める?
- 概念的に構造を揃えよう
- MVCの場合、ユーザーのメンタルモデルをコンピュータモデルに持ち込む
- どこまで業務モデルに合わせる?
- サブシステム・パッケージ・クラス・メソッド・変数?
- 概念的に構造を揃えよう
- 考え方を示している
座談
bouded contextをどう訳すかに悩んだ
- コンテキスト境界?
- 境界づけられたコンテキスト
言葉とは差でしかない
- コメント欄> ソシュールですね
軽量DDDと言われがちですが、実装から入るのもありでは
- Howだけでは実装できないので、実装中におのずとWhatと向き合うことになる
POEAA?
- エンタープライズ アプリケーションアーキテクチャパターン本
-
- 本はどういうエクリチュールで書いているのかが大事
エヴァンス本はソフトウェアエンジニアの人間賛歌
主役はValue Object、大きな単位で見る時はパッケージ
- 三部四部はパッケージの話
- 責務のレイヤーとか
- 三部四部はパッケージの話
パッケージを可視化するツール
- 意外とJIGで視覚的な図を出してみるとパッケージの依存関係が思ってたのと逆になってたりする
- https://github.com/dddjava/jig
- 特に値オブジェクトまで作るとなると、そういう全体像がないものが多すぎて脳がオーバーフローする
- https://github.com/dddjava/jig
- 意外とJIGで視覚的な図を出してみるとパッケージの依存関係が思ってたのと逆になってたりする
パッケージで区別して、パッケージで認識合わせするだけでも価値がある
サブシステム 〜 変数どこまできっちりDDDのニュアンスを適用するか?
しなやかな設計の章を読もう
メイヤー本はおすすめ
- バートランド・メイヤー
コメント欄> 今までDDD本を新規メンバーに読んどいてとすると誰も完読した経験がないです。ここへの対策何かあったりしますでしょうか(苦笑
- 1部と3部だけでいいんじゃないですか
- 要約文を提出させるとかw
- 太字のところ、導入部のみだけとか
自分のツイート
三部は「リファクタリング」「アナリシスパターン」「デザインパターン」たちが登場して一丸となって複雑系と立ち向かっていくのでアベンジャーズみたいで好き #エヴァンス本のススメ
— いいね (@hiyoriaya) December 16, 2021
ドメインビジョン設計文イントロにめっちゃいいなと思ったんだけど、現場だと使われてないのねw #エヴァンス本のススメ
— いいね (@hiyoriaya) December 16, 2021
ドメインと向き合うことで自分が何を提供してるかの輪郭が見えて開発体験が上がるのはありそう #エヴァンス本のススメ
— いいね (@hiyoriaya) December 16, 2021