大前提

具体例は多少古いものも多いが、考え方はとても参考になる、という本。

たびたび言われることだが、例の図 (The Clean Architecture) について学ぶ本ではまったくないし、原則の名前とか、そういうのも別に忘れていいと思っている。

特にフロントエンドエンジニアが読む場合は このあたり を副読本にしてもよいかも。

ためになったところ

最初から最後まで、手を変え品を変え一生以下のようなことを言い続けているところ。

• 依存関係とその向きを意識しよう
• 「同じ理由、タイミングで変更されるコードを密結合にする」vs「関係のないコードを疎結合にする」のバランスを取り続けよう
• 安定したものに依存し、変更が多いものに依存しないようにしよう
• 詳細の決定をできるだけ遅らせよう
• 強い境界と弱い境界を使い分けよう

感想

いきなり座学として読むというよりは、現場でコードを設計して悪戦苦闘した経験のある人が読むと効果が高い本だと思う。たとえば Humble Object Pattern という名前だけ頑張って覚えても仕方ないが、「なんかテスト書きづらいな」とか少しでも悩んだことがあると一発で考え方がインストールされるはず。

AIメインでコードを書くときにも治安を保ちやすくなる考え方が満載である。