「脳に収まるコード」がSOLID原則・DDD理解のカギ

プログラミング学習の初期段階で、SOLID原則やDDD（ドメイン駆動設計）といった設計思想に触れたものの、その抽象度の高さに戸惑った経験はありませんか？ 私もそうでした。しかし、Mark Seemann氏の著書「Code That Fits in Your Head: Heuristics for Software Engineering」との出会い、そしてoginoさんの記事「読みやすいコード」を依存グラフで考えるが、私の理解を大きく前進させました。

Seemann氏の書籍で強調されていたのは、人間の認知能力の限界を考慮したコードの書き方。つまり、「脳に収まるコード」を書くことの重要性です。

「脳に収まるコード」という羅針盤

Mark Seemann氏の言う「Code That Fits in Your Head」とは、開発者が一度に理解し、推論し、記憶できる範囲のコードを書くということ。この視点を持つことで、SOLID原則やDDDの抽象的な概念が、具体的なコーディングの指針として捉えられるようになりました。

SOLID原則：「脳に収まるコード」を実現するための手段

SOLID原則は、「脳に収まるコード」を書くための具体的な手段となります。

• SRP（単一責任の原則）： 一つのクラスは、一つの明確な「責任」だけを持つべきです。役割がハッキリすることで、コードの目的が分かりやすくなり、頭の中で整理しやすくなります。「ユーザー情報の保存」と「メール送信」を一つのクラスに詰め込むのではなく、それぞれの役割を持つクラスに分けることで、各クラスのやることがスッキリします。
• OCP（開放/閉鎖の原則）： 今あるコードはなるべく触らずに、新しい機能を追加できるように設計しましょう、という考え方です。これにより、コードの安定性が高まり、後から変更するときに「ここもあっちも…」とあちこちのコードを追いかける必要がなくなり、頭の中が混乱しにくくなります。
• LSP（リスコフの置換原則）： 親クラスの代わりに子クラスを使っても、プログラムがちゃんと動くようにしましょう、という原則です。これによって、コードの振る舞いが予測しやすくなり、「あれ？この場合どうなるんだ？」と頭を悩ませる場面が減ります。
• ISP（インターフェース分離の原則）： 必要のない機能はインターフェースに含めるべきではありません。必要な機能だけを持つ小さなインターフェースにすることで、コードを使う側が「何が必要なのか」を迷わずに済み、頭の中がスッキリします。
• DIP（依存性逆転の原則）： 具体的なもの（クラス）に直接頼るのではなく、抽象的なもの（インターフェースなど）に頼るようにしましょう、という考え方です。これによって、コードの柔軟性が高まり、それぞれの部分が独立して理解しやすくなります。oginoさんの記事で示されていたように、依存グラフの複雑さを抑える効果があります。

DDD：「脳に収まる」単位で複雑なドメインを理解する

DDDも、「脳に収まる」という視点と深く結びついています。

• 境界づけられたコンテキスト： 複雑なドメインを意味的にまとまった「境界づけられたコンテキスト」に分割することで、各領域のモデルを独立して理解しやすくします。それぞれのコンテキストは、私たちの脳が把握できる程度の複雑さに保たれます。
• ユビキタス言語： ビジネスの専門家と開発者が共有する明確な言語は、コードの意図を曖昧にすることなく、直接的に伝えます。

「脳に収まるコード」は学習の道しるべ

oginoさんの記事で示されていたように、コードの依存関係は、システムの複雑さを測る上で重要な要素です。依存グラフが複雑になるほど、コードの理解は困難になります。

「理解しやすいコード」＝「脳に収まるコード」という考え方を持つことは、SOLID原則やDDDといった抽象的な概念を、具体的なコーディングの実践と結びつけるための強力な羅針盤となります。

コードが読みやすく、構造が分かりやすいほど、「なぜこのような設計になっているんだろう？」「この原則は何のためにあるんだろう？」という疑問に対する答えが見つけやすくなります。さらに、依存グラフの視点を加えることで、コードの依存関係を意識した設計が重要であることが理解できます。

まとめ：「脳に収まるコード」でコードは自然と整理される

難解な理論を丸暗記するよりも、Mark Seemann氏の著書から得た「脳に収まるコード」という視点と、oginoさんの記事で示された依存グラフを意識することが、深い理解と実践への近道です。この視点を持つことで、SOLID原則やDDDの理解が深まり、より効果的で、脳に優しく、そしてビジネス価値の高いコードを書くことができるようになるでしょう。