実践ドメイン駆動設計やエリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)なんか読んでいるけど、実際にはどうやりゃいいのかなというところがちょっとでも情報つかめるならと、行ってきました。
- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (130件) を見る
質疑応答でドキュメントはどうすればいいのか、みたいなところが質問に出ていたけど結局のところ業務知識が豊富な技術者を作り上げるorドキュメントを書いて業務知識を残すという作業のコストでどっちがコスト低いかというところなんだろうか。でも、新規ならまだしもこれまでに積み重なってきたルール類を持つ業務だったりしたら、先にドキュメントとして残すなり作るなりのコストを払ったほうがのちのち良いような気がします。メンテは必要だけど、それこそその人の持ってる知識がバージョンアップされるかどうかもある意味メンテなので、書くほうがいいんじゃないかなぁ。
ただ実装そのまま書いたようなものとかは無駄だと思うので、そういうのはいらない。そのへんはまず「コードを書こう」でいいかと。
あとフロントエンドとDDDの話で個人的に思ってるのは、もうでかい規模だと丸まる一つ別のドメインとして考えるほうがいいのかなーという気がしないでもない。と思ったら同じ日に別の場所でやってたイベントで大型フロントエンド開発におけるTypeScriptとDDD // Speaker Deckという発表があったらしい。この二槽式というアプローチはわりと納得感があるので、今後考えてみたい。
以下、メモ。
ドメイン駆動設計のためのオブジェクト指向入門（増田さん)
- 実装に振り切った内容、具体例、増田さんのベスト
- 転職支援サビースでの事例で説明
- 基礎知識
- ドメイン駆動設計
- オブジェクト指向設計(具体的なXPの話)
- やって楽になった
- データクラスと昨日クラスを分けると、機能クラスにコードの重複が増え変更が飛び火する
- 変更した箇所のテストOKならほかもOKという確信（実際OKかどうかはまた別）
- ドメインを学び学んだことをコードで表現
- 表層の設計はそうなっているけど、実際のところ変更すると苦しいなどという話がある
- じゃあどうするのか？どうしたら楽になるのかというところを示す
- 業務ロジックが散らばってる => つらい、いかにドメイン層に押し込めるか
- ドメイン層のオブジェクト
- 事例
- 転職支援サービス
- ドメイン層の隔離 中級でだいぶ楽になる
- 中級をがんばってやるのが価値になる
- オブジェクトとSQLのマッピングで行ける
- メトリクスとるとドメイン層のクラス数が多くなる
- 集約1つに対して10のクラスがぶら下がる
- クラスの行数は大体30〜60行、シンプル！
- 仕事に対して、勤務条件、給与、休暇……などいろいろぶらさがるので、大体クラス数は膨れ上がる
- 顧客の下にいろいろある、仕事の下にいろいろある
- ドメインオブジェクト「善い部品」
- 分解のしやすさ、組み立てやすさ、わかりやすさ、連続性、保護性
- エヴァンス本10章に善い部品の基準
- 参照オブジェクト(Entityパターン)
- 関心ごとへの参照点
- 顧客との会話の語彙の起点
- 値オブジェクトにロジックをかき集められたらだいぶ変わる
- 転職回数なんかを数値ではなく、値オブジェクトとしてもつ
- 値オブジェクトでコードが安定する
- 一覧オブジェクト
- 区分オブジェクト
- 振る舞いを持ったEnum
- if文/switch文を描かない工夫
- 関心ごとの明示的なコード表現
- HowよりWhat
- 汎用 => 限定
- 学び方のヒント(メイヤー本の受け売り)
- 用語を学ぶ
- 実際にコードを書く
- 読みなおす
- 質疑
- 使う人とそれがしたいものはなにか（ユーザストーリーマッピングと同じ）
- どういう業務なのか
フロントエンドはDDDの夢を見るか ゆきーんさん
- 求職者向け転職支援サービス
- knockout.jsつらそう
- クライアントがデザイン => 特に考えることもなくはじめる => 突然フロントエンドも担当
- 画面は使う方の関心が強いところ
- ドメインモデルを蒸留できるところまでいけてなかったので、ヘルプとの連携もうまくいかず => 仕切り直し
- ドメインモデルと画面
- ある日追加要件
- ドメインモデルと画面の関係
- デザイナさんとコミュニケーションを取りやすかった
- デザイナさんが確認しやすかった
- URLが長くなる！（IEの制限が……）
- CSS難しい
- スタイルはドメインを横断する
- OOCSS
- JavaScriptとDDD
- JavaScriptを書けば書くほどDDDから遠ざかっていく……
- ドメインモデルをそのままJavaScriptに持っていけるようにしてみた
- JavaScriptのドメインモデルがあるという発想
ドメイン駆動設計を軽快に実践するための はるじっくさん
- 重厚さ
- 軽快さ
- コードファースト
- モデル図はスナップショット
- ドメインエキスパートを待たない
- フィードバックは動くUIからで良しとする
- モデルを洗練していくための素早いフィードバックループ
- 使う人からのフィードバック プレゼンテーション層
- テスト書きにくい、読めるテストが書けない アプリケーション層
- データソース層はノイズになるフィードバックが多い
- 集約ルートが開発の基本単位
- プレゼンテーション層まで作ってしまう
- すっかすかな状態でも動く状態まで持っていく
- 動かない状態 => フィードバックが長い、動く状態 => 短い
- テストを書く
- 初回のフィードバックはない
- 実装していくなかでいろいろ来る
- プレゼンテーション層の実装
- プログラマー以外の人からフィードバックがもらえる
- コードから得られないもの
- 集約をまたぐ俯瞰視点からの違和感や不整合 => 深いモデルに到達するためには必要か
- 最初は貧血症でもいい
- 漏れでた業務知識を後からでもドメインモデルに戻せるようにする
