Closed matzryo closed 6 years ago
第一章 DDDってなに?
DDDは技術的パターンとかノウハウ集ではない。設計理論。
アジャイルみたいだなー。スクラムみたいのないかなー。
ドメインエキスパート ドメインモデル
・ソフトを理解しているのが開発者だけ、という状況をなくせる => こうなればいいな。
いままではコードとお客の発言のギャップがあった。開発の翻訳が必要だった
第二章 ユビキタス言語ってなに?
予断
用語の統一。本ドメインのために言葉を制限する。 自然言語のサブセット
ユビキタス言語は、ドメインエキスパートが普段使っていることばとも違う。チーム全員で共有する言葉。
ドメインエキスパートの使っている用語、フレーズを観察することが、ユビキタス言語を見つけるのに有効…ということは、やっぱりドメインエキスパートの言葉は重要なのか。
言葉の排除にポイントがあるのかな。一物一名。
これって、日本語英語混在環境だとハードル上がるのかな。英語圏ならもっと楽そう
だいたい同じだけどちょっと違うものにも、各々適切な名前をつける。
第3章 ドメインモデル
予断
ユビキタス言語で構成された、現実の関心事項がモデル化されたもの。
ソフトウェアモデルとオブジェクトモデルの関係がわからん。包含?どっちもコード?
ドメインモデル貧血症。ドメインモデルを呼称しているけど、たんなるデータ置き場。
第4章 境界づけられたコンテキストって?
予断
インターフェースの話?ドメインモデルの話?
ドメインの前提の話。アカウントという言葉は銀行取引コンテキストでは口座。文学コンテキストでは報告書。単語の意味は文脈がないと確定できない。
サーバーサイドのコンテキストと、クライアントサイドのコンテキストが各々境界づけられることもある。
ほんと?そんな程度で分割していいの?
大切なのは現状をそのまま図にすること、らしい。
食材管理アプリでいうと、賞味期限管理とレシピ検索は別のサブドメインに属する。
予想よりも区切りが細かいな。
賞味期限のサーバーコンテキスト、 賞味期限のクライアントコンテキスト がわかれることもある。
細かすぎない? まあ、現実的にわかれてしまってたらそれを反映させるべき。
キャベツは賞味期限管理のコンテキストだと食品、 レシピ検索だと材料。
たしかになー
第5章 コンテキストマップ
予断 さっきのドメインとコンテキストを図示したもの
第6章 コンテキストマップを活用する
予断 マップを活用して、チームでコミュニケーションを取る。
順応者、腐敗防止層、は実際つかいそう。
パターン、実際にDDDやり始めてから参照しそう。
予断
ドメイン駆動設計。
お客様の言葉をコードにおとしこむことにこだわる。
実際をコードにきっちり対応させる技術。
そうすると、コードリーディングの負担がなくなる。
内部仕様が難しいアプリなんてそんなにない。