エリック・エヴァンスのドメイン駆動設計
https://gyazo.com/f6d31199de5e1f02cc4e72a8631ea378
感想
本質を3行くらいでまとめる
DDDは泥臭い
DDDは言語化ゲー
DDDはミニマリズム
序盤
継続的学習
開発時点では十分にドメインを理解していないので、理解し続けないといけないね
知識の噛み砕きをしておけば、（ドメインについて学ぶ部分は）後からガンガン楽になってくる
もちろん設計スキルや技術の学習も大事だが、「ドメインの」学習も必須
https://gyazo.com/311c50b6f520721ca69bcd7f20886d58
table:t
利口なUI UIにビジネスロジックぶっこんだモノリス。小さいアプリならこれが一番いい ---
---
サービス(DDD) 状態を持たず、どのオブジェクトにも属さない操作（独立したI/Fで提供する 集約(DDD) 関連するオブジェクトの集まり。ルートが一つだけあって常にこいつ経由で操作。 ---
モジュール(DDD) モデルを概念的に分割した単位。技術的容易性よりも概念的わかりやすさを重視すべし。 独立したクラス
必要最小限に低結合なクラスのこと
どれだけ依存を取り除けるかが肝
「その依存、本当に必要なん？？」
認知負荷が小さくて済む
単独でテストできるようになる
閉じた操作
実数が乗算の下で閉じているという例
宣言的な設計
Terraformなどでもう知ってるsta.icon
確立された形式主義を使う
難しい言い方だが、たとえば数学の体系で表現すれば数学的に使えるのでやりやすいということ
自前で新しいプロトコル考えるよりも、この既存の形式に従わせた方が楽ってことやんなsta.icon
https://gyazo.com/499a44828f4934b01be2484eaa5f25d9
モデルの整合性に関するナビゲーションマップ p341より
sta.icon
現実的に、一つのモデルで統一しきることは不可能
大規模だと特に
境界引いてモデルを分けるしかない
世の中の複雑性と向き合うための、現時点の現実的な解
継続的な統合
コンテキスト同士のマージを継続的に行うこと
1日1回はやりたいね、アジャイルでもそうしてるよね言うてるsta.icon
table:紛らわしいのでまとめる
順応者 顧客の言いなりになる（開き直って従いに行く（顧客が供給者側の意見聞いてくれないシチュに 腐敗防止層 お互いに間接的に連携（ファサードを使う table:t
公表された言語 世の中のプロトコル（規格にできるレベルのブツ）使いましょう or なければ新たにつくってそれ使いましょう https://gyazo.com/4ded85a66a42efe666018632816f725e
戦略的蒸留のためのナビゲーションマップ p406
table:ややこしいので一言でまとめる
汎用サブドメイン ドメインのうちコアドメインでない部分（凝集して汎化して使い回せるようにする） 隔離されたコア 汎用サブドメイン化（つまり汎化）できないものはこれをする ---
強調されたコア 同上、補足資料。コアドメインの解説。3-7ページくらい ---
凝集されたメカニズム ドメイン中の煩雑なメソッドを切り出したもの。例: 人の操作をグラフ理論frameworkで切り出す ---
misc
オブジェクトはスペシャリストだが、開発者はジェネラリストである
うまくいっているプロジェクトには、他人のことに首を突っ込む人々が多い。開発者がフレームワークを試し、アーキテクトがアプリケーションコードを書く。全員が全員と話をする。これは効果的な混沌だ。
オブジェクトはスペシャリスト的に明快に定義して、それを使う人達はそれらを何でも使えるジェネラリスト的にするってのが経験則的なベストっぽいなsta.icon
汎用サブドメインをくくりだすことで雑音が減り、凝集されたメカニズムによって複雑な操作がカプセル化される。
政治的な関係や経営陣の命令で制御されることも多い
コンテキストマップつくって現実的な変換を選んでいくしかないわね言うてる
複数のチームが1コンテキストに一緒に取り組むのは難しい
Others
1日1枚でグラレコ風にまとめる試み
AWSのSAの人
一通り部品化した
いったんこの辺で終わるか
最後に本質を5行くらいでまとめたいな
1ヶ月かかったけど、一通りパターンをメモ取った
done
2021/10/29 からだから、1.3ヶ月くらいかかってしまったわね
さあ、じっくりまとめていくわよ……
96%
用語集と索引充実していてありがたい
93%
終盤の大規模パートはマジで意味わからん
ほぼ抽象だし、sta.iconも大規模組織での労働なんてほとんど経験したことないからピンと来ない
80%
中々進まない。他の本読んでるし、夜とかにふらっと読むには重すぎる。
60%
会計の例が続いてるけどさっぱりわからん
一つ前の塗料の例はわかりやすかったが、こういうビジネスドメイン系は本当にわからん
一周目だし、このレベルの理解はいったん諦めて、サクサク読み飛ばすことにしようsta.icon
49%
厳密に設計することが大事と強調している
sta.iconの直感とも合っている
「だよな」
ここまで言語化して合わせに行かないとダメだよな
何が凄いかってこのレベルの言語化とイテレーションを実際に巻き込んで行動に落とし込めてることだよな
言語化についてきてくれる顧客やチームメンバー、sta.iconは全く想像できない
僕の（仕事上での）観測範囲では皆無に等しい
40%
例がいちいちわかりづらい
貨物とか銀行とかドメインゴッリゴリのジャンルばっかやんね
もっと誰でも知ってそうな例なかったのかしらsta.icon
他の本でも何度も経験あるけど、下手すぎない？
音ゲーアプリケーションの例を挙げていきなり「レート」「スコア」「リザルト」とか言い出すのと同じようなもんでしょ
それとも何かな、貨物とか銀行って（この本読むようなエンジニアには）一般常識？？
たとえば「ローン出資とは、ローンにおける特定の出資者の分担額を表す」
ローンも出資もわからん
出資は「金くれてやろう」「代わりにお前の株券寄越せ（儲かったら配当もらうで）」
ローンは？
なんか銀行用語と投資用語が混在してて意味不明
例は銀行ドメインだから銀行用語
でも出資って銀行用語じゃなくない？
↑ こんなことに長々と悩むわけですよ。アホらしい。。
いいや、ふーんで流そうsta.icon
と思ってたらシンプルな設計になってローン出資等の用語全部消えたｗ(41%)
「ローン出資」が銀行用語ではないことに気づいた。
やっぱりそうじゃんよ
20%
what?
重厚だなぁ。今のところ読み物だが、それでも休日2日使っても半分もたぶん行かない
15%
なるほど、お互い歩み寄った中間地点・共通部分の「基礎」をイテレーティブかつコラボレーティブにつくりあげていくわけか
sta.iconは一人で仕事するときは割とやっているが、これをn人でやると（たとえば）このDDDになるわけか
使い分けが興味深い
ユビキタス言語は語彙集合
モデルは開発者とドメインエキスパート双方が使う共通概念（とその関連）
境界づけられたコンテキスト（？）だっけ、ドメインエキスパート側の過度な専門や開発者側の過度な専門には立ち寄らず、両者にとって必要な共通部分にリーチする
設計はモデルの忠実な再現（コードに押し込むための世界）担当
コードは詳細表現担当
ドキュメントはコードと設計の補足担当
---
https://gyazo.com/aebb02ab6b048ec3be5530a00d071e5a
たぶんこんな感じ？sta.icon
しかし例はさっぱり頭に入ってこない
輸送とPCBの例があるけどどっちもさっぱり
これらを理解するためには気合い入れて（たとえばここでノート取るなどして）把握しなきゃいけないだろう
読んで頭だけで、は無理だ。。。
7%
共通言語で開発者とドメインエキスパートが双方とも会話できるというが、そんな共通言語なんてつくれるのか？sta.icon*2
エンジニアあるあるだろうが、Domainerそんなに賢くないのではと考えてしまう
めっちゃ半信半疑
さあ、どんなやり方や考え方を見せてくれるんだい？
それはそうと、ドメインと向き合うの辛いな。。。
そしてそれじゃダメだよと現在進行系で非難されているｗ
そしてベースはアジャイルでありコミュニケーション前提である
買ってしまった
職場で「かんたんに分かる本」が緩募されていて、俺も知りたかったが、無さそうだった
もう原典あたるしかないやろ
うぬぼれだったかどうかは読了後に評価しようsta.icon
読了したので改めて
うぬぼれじゃないと思う
仕事で使おうと思えば使えるかなとも思える
が、sta.iconがそもそもコミュニケーションもドメインも嫌いなのでやりたくないけど……
エンジニアとして自分が抱いてる直感とも大差ない
無論、自分が知らない部分は「へぇそうなんだ」しかできないけど
ドメイン理解するのは苦痛
サンプルの輸送とか銀行とか理解するの苦痛だった
というか途中で投げた