関連性の強いデータとロジックだけを集めることで凝集度の高いクラスが出来上がり、意図が明確で分かりやすくなると同時に変更の副作用が外に影響しにくくなる（疎結合になる） サービスにロジックを書かない　サービスがさらにシナリオクラスを参照して、そのシナリオクラスが様々なドメインクラスを参照する形がよい。

設計ドキュメントを書かずにソースコード自体をドキュメントとして運用するという考え方は魅力的だが、メンバが技術にもドキュメンテーション力や要件理解にも全て優れていないと成立しないような。おまけにコードが読めないクライアントへの成果物として設計書は必要になる。魅力的ではあるが、こんな理想的な開発を出来ているシステムベンダーなんてあるんだろうか。完全自社の中規模くらいまでのシステムなら可能なんだろうか。

少し違和感を覚えたのは 「開発の進め方がウォータフォールからアジャイル?になったのがオブジェクト指向の影響」と読み取れちゃう9章の導入（オブジェクト指向の少しずつ要求に対応させやすい形はコードの再利用性問題とビジネス側の問題の気持ちなので）と 8章「DELETE, PUTを使わず表現」(使ってもいいと思っちゃうが、updateはdeleteとcreateとは矛盾するもんなぁ...)と「項目別にエンドポイントを作ろう」（PATCHで対応でもと思ったけど、影響範囲が後に響くか...） 自分の脳が慣れてない