「クラス設計の鉄則」執筆ノート

『Software Design 5月号』の第２特集「クラス設計の鉄則」を寄稿しました。 gihyo.jp

第２特集の概要と、今回はとりあげなかった、SOLID、GoFデザインパターン、凝集度と結合度について、私がどう捉えているかを説明します。

概要

第２特集のクラス設計の鉄則は３章で構成されています。概要は次の通りです。

第1章：クラス設計再入門
モジュール性・関心の分離・依存関係を意識する

第2章：迷わないクラス設計の指針
アプリケーション開発の実践例から考える現代的な設計方針

第3章：設計の落とし穴対策
コードから問題を検知する着眼点と改善方法

第１章：クラス設計再入門

この章は、クラス設計の基礎として、ソフトウェア設計の三つの視点を紹介しています。

ソフトウェアシステム構築の基本課題として「複雑さ」と「変更容易性」に焦点を合わせ、二つの課題に取り組むための考え方として、「モジュール性」「関心の分離」「依存関係」というソフトウェア設計の三つの視点をクラス設計と関連づけながら説明しています。

モジュール性が低い例として大きな泥団子を取り上げ、モジュール分割のアプローチとして、手続き、関数、クラスの三つを比較しながら、クラス設計の考え方の特徴を説明しました。

関心の分離を意識したクラス設計として、入出力と計算判断の分離の重要性を強調しました。またアプリケーション独自のデータ型としてクラスを設計する効果、クラスの可視性をうまく設計して詳細を見えなくすることの効果をとりあげました。

依存関係については、コードの重複という暗黙の依存関係の問題とその改善策としてのクラス設計を説明しました。そして、クラスを使って暗黙の依存関係を明示的にすることで、より適切な依存関係に改善する道筋をとりあげました。

第２章：迷わないクラス設計の指針

この章では、第１章で説明したモジュール性、関心の分離、依存関係の三つの視点でのクラス設計の具体例として、アプリケーションを構成するクラスを次のカテゴリーに分類して、それぞれの設計指針を説明しています。

• 計算判断クラス
• アプリケーションサービスクラス
• プレゼンテーションクラス
• データソースクラス

また、現代的なクラス設計の指針として、以下を取り上げました。

• 可変より不変を選ぶ
• エンティティより値を選ぶ
• 継承よりコンポジションを選ぶ

第３章：設計の落とし穴対策

この章では、設計がうまくいっていないことを、ソースコードから検知し、それを改善する方法について説明しました。

ケントベック氏の『Tidy First?』とマーチンファウラー氏の『リファクタリング（第１版）』のエッセンスのような内容です。

取り上げた主な内容は、以下の通りです。

• 乱雑になったコードを整頓する
• 長いメソッドを改善する
• 大きなクラスを改善する
• データだけのクラス、ロジックだけのクラスを改善する

記事で取り上げなかった設計の考え方

クラス設計の考え方としては、以下の内容を参考にしている方も多いと思います。

• SOLID
• GoFデザインパターン
• 凝集度と結合度

今回の「クラス設計の鉄則」の執筆にあたり、これらの内容に触れることも検討しましたが、最終的には、まったく触れませんでした。

その理由について、簡単に補足しておきます。

まず、この三つについてさまざまな情報が出回っているので、この記事で改めて取り上げる価値はあまりないように感じたからです。

また、さまざまな情報が出回っているわりには、クラス設計に悩んでいる人が多いという状況を考えると、SOLID、GoFデザインパターン、凝集度と結合度の説明は、クラス設計の初学者から中級者にとっては、あまり役に立っていないのではないか、と考えました。

ですので、この第２特集では、より基本的で一般的な設計視点である「モジュール性」「関心の分離」「依存関係」から始めて、実践的なクラス設計の考え方として、アプリケーションを構成するクラスの分類とそれぞれの設計の要点を説明し、具体的な設計のやり方として、ソースコードに現れる不適切な設計を検知し改善するための技法を説明しました。

私は、SOLID、GoFデザインバターン、凝集度と結合度の三つは、この特集で説明したような内容を一通り習得できたレベルのエンジニアがさらにレベルアップするために利用できる内容と位置付けています。

初学者向けには、あまり適切ではないと私が感じている点を簡単にまとめておきます。

SOLID

設計の視点、粒度、適用できる状況などが、５つの原則でばらばらな点が初学者向けではないと感じています。

例えば、S: Single Responsibility Principle（単一責任の原則）は、一般的でどのクラス設計でも共通して使える考え方です。

それに対して、L: Liskov Substitution Principle（リスコフの置換原則）とD: Dependency Inversion Principle（依存性逆転の原則）の二つの原則は、かなり特殊な状況に限定された設計原則です。アプリケーション開発で、この原則を意識すべき状況は限定されます。

また、O: Open/Closed Principle（オープン/クローズドの原則）とI: Interface Segregation Principle（インターフェース分離の原則）の二つの原則は、抽象度が高く、具体的にどういう状況で、どういう設計をすることが適切かを判断する指針としては、初学者には理解が難しすぎるように思います。

また、５つの原則は、排他的網羅を意識した分類体系のようなものではない点も、上級者には参考になっても、初学者向けの指針としては適切ではないように思います。

GoFデザインパターン

これは、かなり上級者向けの内容だと思っています。扱っている設計課題とその解決策は、初学者が実際の業務で参考にするような内容ではないと思います。

また、GoFデザインパターンが提示された1990年代であれば、これらのパターンをアプリケーション開発者が習得して利用する機会もそれなりにありました。しかし、最近では、プログラミング言語、フレームワーク、ライブラリなどに、さまざまなデザインパターンが取り込まれています。その結果、アプリケーション開発者がデザインパターンを直接意識する機会は少なくなったと思います。

フレームワークやライブラリを理解し適切に使うために、GoFデザインパターンの知識が役に立つことはありますが、初学者がクラス設計を学ぶための知識としては、優先度の高い知識ではないように思います。

凝集度と結合度

凝集度と結合度は、ソフトウェア設計の考え方として、いまでも学ぶ価値は大きいと思います。

しかし、1970年代の議論をそのまま持ってきたような説明では、現代的なクラス設計の指針としては、役に立たないように思います。 またクラス設計という文脈では、1970年代の議論は、クラスというモジュール化の手段が一般的になる前の議論のため、そのままでは初学者向けのクラス設計の指針として扱うのは、かなり無理があるように思います。

システムを捉える５つの視点

システムと呼ばれるものは、さまざまな要素の関係が複雑で、要素とその関係が変動し、予測が難しく、とらえにくいものである。

システムと呼ばれるものに取り組む時に、自分が意識している５つの視点を簡単にまとめてみた。

①文脈で考える

システムを取り巻く環境や、そのシステムがおかれた状況が、そのシステムのさまざまな特徴を生み出しているという、という捉え方。この環境や状況が、システムが存在し持続する文脈となる。

システムと環境は相互に作用する関係にある。つまり、環境が変わればシステムが変化し、システムが変われば、環境になんらかの変化が生まれる。

システムが人工物の場合、取り巻く環境を構成する要素は、三つに分類できる。

• その人工物を作る理由や目的
• その人工物を作るために利用可能な資源
• その人工物を作るうえでの制約

ソフトウェアシステムを設計する場合、文脈で考えるということは、ソフトウェアシステムの目的、利用可能な資源、作るうえでの制約を考えるということ。

②全体と部分で考える

システムは一つの全体であり、同時に、部分の集合である。

システムを捉える視点として、全体を見ることと、部分を見ることを組み合わせることになる。

意識的に（細部にとらわれず）全体を見る、あるいは、意識的に（全体から切り離して）部分を見る、ということが役に立つ。

無意識に部分だけを見る、ということが起きがちなので、意識的に細部にとらわれずに全体を見ることに重きを置くことが、結果として、部分を適切に扱うことにつながる。

全体を見るためのさまざまな視点の中で、文脈で考える視点がシステムを全体として捉え理解するために役に立つことが多い。

③関係で考える

個々の構成要素は、実体として、比較的、とらえやすい。それに対し、要素と要素がどういう関係にあるかは、とらえにくい。なんとなくつながりがありそうだと感じることと、そのつながりを分析し関係に名前をつけること（関係の言語化）との間には、大きな隔たりがある。

関係で考えることは難しい。だからこそ、関係で考えてみることが役に立つ。最初は見えていなかった関係があきらかになることで、システムの輪郭と構造が明らかになってくる。

全体と部分で考える時も、関係で考える視点が役に立つ。他の要素との関係を考えずに、個々の要素（部分）に注目しているだけでは、全体を見ることができない。要素間のつながりを考えてみることで、全体を見る手がかりが増えてくる。

文脈で考える視点とは、文脈と対象システムとの関係を考えることである。

④ネットワークで考える

要素と要素の関係を捉える時に、要素どうしを対等に考えると、その関係はネットワーク構造になる。

要素と要素の関係を包含関係や上限関係で考えると、その関係はツリー構造となる。

ツリー構造は、整理されているように見えるが、システムは基本的にツリー構造では整理できない。 もし、ツリー構造で整理することが効果的であるなら、整理の対象は、システムと呼ぶよりは、もっと単純で静的な存在としてとらえたほうがよいということ。

ネットワーク構造にもいくつかのパターンがある。 極端な例として、一つの中心となる要素に、他の要素がつながっている、周辺の要素どうしには関係がない、という一点集中型がある。 別の極端な例として、すべての要素がつながっている完全（？）なネットワーク構造がある。 また、複雑なネットワークモデルの一つに、要素間のつながりがランダムに（確率論的に）発生するというランダムネットワークモデルがある。

現実のシステムの構造としては、いずれも単純すぎる。

多くのシステムは、スケールフリーネットワークと呼ばれる特徴を持つ。 スケールフリーネットワークとは、簡単に言えば、ごく少数とつながる多数の要素と、多数の要素とつながるごく少数の要素で成り立つネットワーク構造である。

システムをこのスケールフリーネットワークとして捉えることが役に立つことが多い。特に、多数の要素がつながるごく少数の要素（ハブ）を特定することが、システムの特徴を捉え、構造を整理することにつながることが多い。

また、ハブと要素の間の属性、例えば距離やなんらかの重みなどを分析することが、システムの特性の発見につながることがある。

⑤プロセスで考える

システムは時間とともに変化する。完全に静止した構造物は、システムではない。

システムを捉える時に、ある時点での静的な構造を考えることは役に立つ。しかし、その静的な構造は、時間とともに変化するというシステムの本質的な特徴を見落とすことにつながる。

システムを捉える時には、時間とともに変化する進行過程で考えることが役に立つ。

進行過程のモデル化の技法としては、一連の活動としてモデル化、一連の出来事（イベント）としてモデル化、状態空間の遷移としてモデル化、などがある。三つのモデルは、活動の結果として出来事が発生し、出来事が状態を遷移させる、という関係になる。

まとめ

ここに書いたことは、アルゴリズムのような方法論ではない。

ソフトウェアシステムの設計のさまざまな失敗と成功から学んだ、私の経験則の言語化である。

システムを理解したり、システムを設計する時に、この５つの視点を意識して使ってみることで、複雑で、あいまいで、一見とらえどころのない対象を、モデル化し、構造を把握し、判断し、次の行動に進むという設計活動を効果的に行うことができるようになる。

マネジメントの知識がドメイン駆動設計を加速する

2023年6月13日開催の設計コミュニティイベント「現場から学ぶモデル駆動の設計 第24回」で発表した資料の説明です。

スライドを公開しています。

概要

今年の三月に出版された佐藤大典さんの『エンジニアのためのマネジメント入門』に書かれている知識は、ドメイン駆動設計を実践する時にとても役に立ちます。

(2023-6-15 「深い洞察に向かうリファクタリング」と「戦略的設計」の内容を加筆）

この本の内容をチームで習得することでドメイン駆動設計をより効果的に進められます。

『エンジニアのためのマネジメント入門』

『ドメイン駆動設計』に取り組む時に、特に関係するのはこの４つの章の内容です。

『ドメイン駆動設計』

エヴァンス氏の『ドメイン駆動設計』は全体は４部で構成されています。

それぞれの部に書かれた内容と『エンジニアのためのマネジメント入門』の内容がどう関係するかを紹介します。

第１部「ドメインモデルを機能させる」とマネジメントの知識

『ドメイン駆動設計』の第１部は、ドメイン駆動設計の目標を説明しています。

スライドのように『エンジニアのためのマネジメント入門』の第２章と第３章の知識は、このドメイン駆動設計の目標と強く関係しています。

「コミュニケーションを支える技術」と「対話のフレームワーク」は、エンジニアが業務知識を習得し設計に反映させていくための基礎となります。

ドメイン駆動設計が重視する「継続的な学習」とイテレイティブな設計の改善活動は「チームのフェーズ」の変化と、その変化（成長）を促進する「６つのリーダーシップのスタイル」の知識が役に立ちます。

第２部「モデル駆動設計の構成要素」とマネジメントの知識

ドメイン駆動設計の「エンティティ」「値オブジェクト」「モジュール（パッケージ）」「集約」は、業務知識を習得し表現するためのパターンです。

ドメイン駆動設計に書かれているパターンを実践するために必要なのは、業務の理解です。

『エンジニアのためのマネジメント入門』で紹介されている、バリューチェーン、オーガニグラフ、営業プロセスは事業活動を理解するための全体地図として使えます。管理会計や収益構造の知識は、業務ルールのwhyを理解し、whatを記述するための基礎知識になります。

そういう業務知識（ドメインの知識）をクラス名やパッケージ名として整理して関連づけていくのがドメイン駆動設計の基本的な活動です。

第３部「深い洞察に向かうリファクタリング」とマネジメントの知識

『ドメイン駆動設計』がほんとうに効果を生み出すのは「深い洞察に向かうリファクタリング」に取り組んだ時です。

そのためには、さまざまな関係者と密度の高いコミュニケーションを繰り返しながら暗黙の概念を掘り起こし、それをプログラミング言語を使って明示的に表現することが必要です。

業務知識の発見と表現の改善を繰り返すためのリファクタリングがドメイン駆動設計の核心の活動です。

この核心の活動を支えるのが「ファシリテーション」の基礎知識であり、「リーダーシップ」であり、「ステークホルダー」の特定と建設的なかかわり方です。自分がわかっている/わかっていない、他人がわかっている/わかっていないの「ジョハリの窓」の理解も、深いモデルに近づくために役にたつでしょう。

また深いモデルにたどり着くためには、オーガニグラフ、ステークホルダーマップ、バリューチェーンなど俯瞰的なものの見方が役に立ちます。特定箇所の深堀をしつつ、それが全体の中でどういう位置づけで、他の要素とどう関係するかを理解することが、ドメイン駆動設計でもマネジメントでもよい成果を生み出します。

SECIモデルの内面化・共同化・表出化・連結化のサイクルは、「深い洞察に向かうリファクタリング」の活動サイクルそのものです。

第４部「戦略的設計」とマネジメントの知識

『ドメイン駆動設計』の戦略的な設計に取り組む時に土台となる知識が『エンジニアのためのマネジメント入門』第4章「組織のマネジメント」と第5章「戦略実現のためのマネジメント」の内容です。

キャリアとしてエンジニアリングマネージャーを目指すかどうかにかかわらず「組織」や「事業戦略」の知識を広げることは『ドメイン駆動設計』を取り入れたソフトウェア開発の基礎であり、また設計活動の軸になります。

異なる境界づけられたコンテキストをどうつなぐかのパターンは、技術的な選択肢というよりは、チーム間や組織間の関係性とコミュニケーションの問題です。「顧客と供給者」の関係を気づくのか、「順応者」や「腐敗防止層」で対応するのか、「別々の道」を選ぶかは、自分たちの組織のバリューチェーンやオーガニグラフの関係をどう捉え、その構造をどうソフトウェアの構造に反映させるか、という設計課題です。

「大規模な構造」の検討は、バリューチェーンやオーガニグラフによるモデル化と直接対応します。

コアドメインを明確にする「蒸留」に必要なのは自社の事業戦略です。事業を存続し発展させていくための競争優位を生み出す中核の活動をどこに求めるかを正しく理解し、それをソフトウェアの設計に活かしていくことで、事業価値を生み出すソフトウエアを開発し発展させていくことができます。

事業戦略が抽象的だったりうまく言語化されていない状況は少なくありません。そのような場合でも、ソフトウェアのどこが複雑になり、どこが重要な変化箇所になることが多いか、というソフトウェアの構造や変更の履歴から、事業戦略を理解する重要な手がかりを得ることができます。そうやってソフトウェアの側から分析していく場合でも、マネジメントの視点からの事業戦略の考え方や枠組みについての知識があれば、より効果的に分析を進めることができます。

『ドメイン駆動設計』の５つの基本アイデア

エヴァンス氏の『ドメイン駆動設計』の背景にある基本アイデアは何かという私の捉え方のメモ書き。

ドメイン駆動設計にはいろいろな側面がある。また書籍『ドメイン駆動設計』は体系だった設計方法論ではなく、設計の考え方とやり方を経験則として言語化してみた、と捉えている。

その経験則（100%ではないが多くの場合に役に立つ原則）の背景にあるエヴァンス氏の基本的な発想は次の５つに要約できると考えている。

ソフトウェアの複雑さは事業活動の複雑さに起因する

技術的な複雑さもあるが、ソフトウェアが複雑になるのは対象領域の複雑さが主たる理由という考え方。

業務アプリケーションであれば、事業活動の複雑さが業務アプリケーションの複雑さの原因と捉える。

ドメイン駆動設計は、この事業活動の複雑さに起因するソフトウェアの複雑さをうまく扱うための工夫、というのが私の捉え方。

ドメイン駆動設計という設計のアプローチを取り入れるなら、まず第一に対象領域の複雑さに焦点を合わせることが大前提になる。

モデル駆動設計の効果

複雑さに取り組む時の工夫の大きな柱がこれ。 モデルと実装を一致させることで複雑さが扱いやすくなる、という考え方。

エヴァンス氏が「まえがき」で紹介している三つのプロジェクトの例で「精緻なモデルを作ったが実装と乖離(かいり)してうまくいかなった」という経験からモデルと実装を強く結びつけ、モデルとコードを相互に作用させながら設計を改善していくという発想が生まれたのだろう。

ドメインモデルの活用

モデルといっても、プロセスモデル、ユースケースモデル、データモデル、状態遷移モデルなどいろいろなモデルがある。

ドメイン駆動設計が「モデル駆動設計」で重視しているのは「ドメインモデル」。エヴァンス氏のドメインモデルの解釈はファウラー氏と同じ「オブジェクト指向」のモデルであることが基本になっている。

ユースケースモデルやデータモデルとの一番の違いは、複雑な業務ロジックをどう記述するかを重視する点。

業務ルールに基づく複雑な計算判断ロジックをうまく整理する方法として、トランザクションスクリプトやテーブルモジュールではなくドメインモデルを選択するという考え方。

また、ドメインモデル作りは、開発者が業務知識を取得する手段の一つであり、関係者が同じ言葉（ユビキタス言語）を使って意図を伝えあう語彙の骨格になり、モデルとコードを一致させる道具である、という発想。

深い洞察に向かうリファクタリングの重要性

設計改善の手法としてかなり普及してきたリファクタリングの考え方を、事業活動を深く理解するための手段として活用する、という発想。

リファクタリングの目的として以下の二つを重視する。

• 暗黙の概念の発見と言語化
• ソフトウェアの発展性の改善

複雑な事業活動で価値を生み出すソフトウェアの開発は、最初からうまくいくわけではない。表面的かつ断片的な知識を元にした設計から出発して、実際に動くプログラムを記述し、そのコードをリファクタリングをしながら、事業活動の深い理解と、ソフトウェアの構造の改善に継続的に取り組みつづけるという発想。

戦略的な設計への取り組み方

規模が大きなソフトウェアを長期的に成長させていくという課題に対する『ドメイン駆動設計』の考え方とやり方。

• コードに責任を持つ開発者が全体的・長期的な設計課題に取り組むことの重要性と効果
• そのために開発の文脈を明確に区切って、全体的・長期的な課題を明確にして扱いやすくする
• 文脈と文脈の境界で生まれる課題とその対応方法の選択肢の検討
• クラス粒度ではあつかえない複雑さの扱い方の工夫（レイヤー構造や蒸留）

『ドメイン駆動設計』の解説記事を書きました

本日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。

Software Design 2023年2月号｜技術評論社

執筆の意図

特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。

重視したこと

1. 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える
2. 全体像を伝えるための図や表を多めにした（ソースコードの例は少ない）
3. 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』（以下『ドメイン駆動設計』）の説明を中心にした
4. ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務知識の解説を多めにした
5. マイクロサービスなど分散アーキテクチャとドメイン駆動設計の関係など、新しめの内容を盛り込んだ

基本的にはエヴァンスさんの『ドメイン駆動設計』の概要の説明です。

まだエヴァンス本を読んだことがない人や、読んだことはあるけどなんかよくわからんかったという人が、この記事を読むことで、全体の流れと要点をつかみ、エヴァンス本を興味深く読めるようになるとよいな、という思いで記事を書きました。

ドメイン駆動設計とは？（本特集記事の第１章）

ドメイン駆動設計の基本的な考え方を説明する情報が少ないと感じていました。 そういう問題意識から、この特集の第1章では『ドメイン駆動設計』の「はじめに」と第１部「ドメインモデルを機能させる」の３つの章をわかりやすく説明しようと考えました。

まず、ドメイン駆動設計の基本的な考え方を以下の図の流れで説明しています。

次に、ドメイン駆動設計という設計のやり方の中心となるドメインモデルとその三つの用途について書いています。（ドメインモデルの作り方は本特集記事の第２章で具体的に説明しています）

また、ドメインモデルを中心にどのようにアプリケーション全体を組み立てるかを、ヘキサゴナル（ポート &アダプタ）アーキテクチャやクリーンアーキテクチャの概要に触れながら説明しています。

ドメインモデルを理解しよう（本特集記事の第２章）

ドメイン駆動設計の中心となるなるドメインモデルの作り方についての解説です。

題材は『ドメイン駆動設計』のあちこちにでてくる国際海上貨物輸送のオーバーブッキングルールです。

図のような単純な理解からはじまり、業務知識を広げながらドメインモデルを成長させていくやり方を説明しています。

オーバーブッキングルールが、国際海上貨物輸送ビジネスにとっていかに重要であるか、そして、どういう複雑さがあるかという業務知識に触れながら、値オブジェクトなどを使ってドメインモデルを組み立てる道筋を紹介してみました。

国際海上貨物輸送の業務そのものについての説明が多めです。そこに興味が持てれば、ドメインモデルを組み立てるパターンの説明も理解しやすいと思います。

業務を理解するために次の三つの視点を組み合わせるやり方を説明しています。ドメインモデルの中心となるのは業務ルールの視点です。他の二つの視点と関連づけることで、業務の理解が立体的になります。

• 業務プロセス
• 業務データ
• 業務ルール

また、業務ロジックを表現するための三つのパターンを簡単に比較しながら、ドメインモデルの特徴を説明しています。

分散アーキテクチャとドメイン駆動設計（本特集記事の第３章）

最近は、分散アーキテクチャやマイクロサービスとの関係でドメイン駆動設計が取り上げられることが増えてきました。 この章では、ドメイン駆動設計の考え方とやり方をどのように分散アーキテクチャに活かしていくかを説明しています。

『ドメイン駆動設計』が書かれた当時は、分散アーキテクチャはそれほど一般的ではありませんでしたが、この本の第4部で紹介されている大規模なシステムに取り組むための「境界づけられたコンテキスト」と「コンテキストマップ」の考え方が、最近では分散アーキテクチャのモデルとして利用されることが多くなってきています。

「境界づけられたコンテキスト」はどう分けたらうまくいくか、「コンテキストマップ」はどうつなげばよいかを設計するための考え方とやり方です。

また、さまざまな業務領域をそれぞれの特性ごとに適切な設計や開発のやリ方を検討するために『ドメイン駆動設計』の「コアドメイン」という考え方が役に立ちます。

ドメイン駆動設計のパターン名と用語集（本特集記事の第５章）

ドメイン駆動設計のパターン名や用語は、意味がわかりにくく、人によって捉え方にばらつきが多いようです。 この章では、主要な用語を取り上げながら、その用語の一般的な意味と『ドメイン駆動設計』という文脈に限定した場合の意味について説明しています。

また、用語の意味は他の用語との関係で理解することで、理解しやすくなります。図のように、主なパターン名と用語を関連づけながら、主要な用語を解説してみました。

設計の手法とアイデアの引き出しを増やす

ドメイン駆動設計は銀の弾丸でもないし、唯一の正しい設計技法でもありません。 しかし、ドメイン駆動設計の考え方とやり方を理解することで、設計の手法やアイデアの引き出しは確実に増えるはずです。

ここで紹介したSoftware Design 2023年2月号の特集記事が設計力を磨きたいと思っているソフトウェア開発者のお役にたてればうれしいかぎりです。

本の紹介『読みやすいコードのガイドライン』

はじめに

良い本です。コードを書く人であればだれでもが気づきと学びがあるでしょう。
特に、コードの規模が大きく長期間にわたってさまざまな関係者が読むことになるプログラムを書く人にはぜひ読んでほしい本です。

gihyo.jp

この本から学べるのは、どちらかというと「やり方」よりも「考え方」です。
書き方の具体例というよりは、良いコードを書くための考え方を、著者の知見に基づいて丁寧かつ具体的に説明しています。 別の言い方をすると、とにかくコードの具体例で「やり方」を覚えたい、という人には合わないかもしれません。
コードの具体例もたくさん登場しますが、それは「考え方」を説明するための例であって、コードの書き方のお手本やサンプルを集めた本ではありません。

サンプルコードはKotlinです。内容は、どちらかといえばユーザーインタフェースよりという印象です。しかし、Kotlinを知らなくてもほぼ問題なく読めますし、「考え方」の本なのでサーバーサイドのプログラミングでも役に立つ内容ばかりです。

この本の内容は次の三つに分けることができます。

• 基本となる考え方の説明（はじめに、1章）
• 自然言語を使った人と人とのコミュニケーション（2章、3章、7章)
• プログラムの構造と複雑さの改善（4章、5章、6章）

それぞれに内容について、概略を紹介します。

基本となる考え方（はじめに、1章）

コードの読みやすさが開発の生産性に与える影響を述べています。
その視点から、コードの読みやすさの指標を４つあげています。

• 単純なコード
• 意図が明確なコード
• 独立性の高いコード
• 構造化されたコード

この本で説明している「読みやすいコード」の考え方を要約した内容です。

また、この考え方にそって、さまざまな一般的な設計原則のなから、以下を取り上げて説明しています。

• ボーイスカウトルール
• YANGI
• KISS
• 単一責任の原則
• 早計な最適化は諸悪の根源

この五つを代表的な原則として選んだ理由として「過剰に適用したとしても比較的悪影響が出にくい」ことをあげているところに、著者の設計原則についての考え方が表れていると感じました。

自然言語を使った人と人とのコミュニケーション（2章、3章、7章)

コードを書くとは、人と人とのコミュニケーションである、という観点で参考になるのが次の三つの章の考え方でしょう。

• 第2章　命名
• 第3章　コメント
• 第7章　コードレビュー

自然言語を使ってうまく意図を伝達するには、どのようなことに気を付ければよいかを説明した内容です。
ソフトウェア開発とはコミュニケーションでありドキュメンテーションである、という考え方が一貫しています。コードの規模が大きく関係者も多い開発の現場で、ほんとうに役に立つ考え方をわかりやすく解説しています。
チーム開発に関わる人にはぜひ読んでほしい内容です。

プログラムの構造と複雑さの改善（4章、5章、6章）

個人的には、この三つの章が特に参考になりました。コードの書き方というよりは、設計がテーマの章だと思います。
コードが複雑になり読みにくくなる原因とその改善策を「状態」「関数」「依存関係」の視点から説明しています。

第4章　状態

状態を単純化する方法がいろいろ紹介されています。
状態の扱いはプログラムを複雑にします。この複雑さの扱い方について、学びの多い章です。
複数の変数を扱うときの「直交性」の大切さ、状態遷移の複雑さを緩和するための「不変性」「べき等性」「巡回と非巡回」などの考え方を具体例や図を使いながら説明してあります。

かなり高度な内容が含まれていると思いますが、それをわかりやすく説明できているのは、著者がソフトウェア開発の現場で、こういう考え方を回りに何度も伝えてきた経験が背景にあるのだろうと感じました。

第5章　関数

関数の動作を予測可能にする、という視点からのコードの書き方を説明しています。
「関数の責任の分割の考え方」と「関数の流れをわかりやすくする工夫とその効果」が説明されています。
「早期リターン」というある意味で単純なテクニックを取り上げて、5ページにわたって背景にある考え方、適用する時の注意点が丁寧に説明されています。こういうところがこの本の特徴であり、この本を読む価値だと思います。

第6章　依存関係

クラスの依存関係というやっかいな課題を「結合度」「方向」「重複」「明示性」の四点から取り上げています。
依存の強さ（結合度）について、7つの結合パターンと結合度の強弱についての説明は、とてもわかりやすく参考になります。考え方自体は従来からあるものですが、従来からの考え方について、いろいろ調べ、それを現場に取り入れてきた著者の知識と経験がにじみ出ている内容だと感じました。
「方向」「重複」「明示性」については、図とサンプルコードが丁寧に作られていて、なかなかの力作だと思いました。この本のもとになったプレゼンテーション、講義、現場での意見交換などからのフィードバックか活かされているのでしょう。

この三つの章は、コードの書き方というよりは設計の考え方とやり方として大いに参考にしてほしい内容です。

関連書籍など

この本に関連した書籍をいくつか取り上げておきます。

O'Reilly Japan - リーダブルコード

コードの書き方についての古典的な名著です。
取り扱っている内容は、本書と重なるところもありますが『リーダブルコード』のほうがコードよりで基礎的な内容だと思います。

『読みやすいコードのガイドライン』はわかりやすく書いてありますが、取り上げている内容や考え方の説明は、初級者向けというよりは中級者向けだと思います。

良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方：書籍案内｜技術評論社

仙塲さん（ミノ駆動さん）のこの本も内容としては重なるところがあります。
仙塲さんの本は、現場の生々しいコード例が豊富で、コードの具体例で学びたい人には、こちらのほうが合うかもしれません。しかしこちらも単なるコードのサンプル集ではなく「設計の考え方」に触れることを強く意識している本です。
リファクタリングを通じた設計改善の指針と具体例という点で、こちらの本も合わせて読むことをお勧めします。

最後に『読みやすいコードのガイドライン』とは少し異なる視点で書かれた本を2冊紹介します。
これらの本の背景にある設計の考え方は、かなりの部分が共通しているので、参考になる点も多いと思います。

達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法：書籍案内｜技術評論社

（拙著です）

変数(variable)と値(value)

はじめてScalaに触れたとき、変数宣言(var)と値宣言（val)を使い分ける言語仕様に、なるほどなあ、と思った。簡単に言えば、変数(var)は再代入できて、値（val)は再代入できない。

プログラミングのスタイルとして、var宣言は命令的なプログラミング、val宣言は宣言的なプログラミングになる。どちらのプログラミングスタイルで書いているかを、varとvalで明示できるわけだ。

Javaだと言語の基本の仕組みはすべてが変数。final宣言をすることで再代入をコンパイルエラーにすることはできる。Javaは、C言語やC++などの命令的なプログラミングの系譜の言語なのですべて変数(variable)というのは、とうぜんの言語仕様だった。

命令的なスタイルから宣言的なスタイルに

命令的なプログラミングでは変数(variable)を使う。宣言的なプログラミングでは値(value)を使う。

再代入可能な変数(variable)は、プログラムの実行時の状態が基本的には不定（不安定）になる。

それに対して再代入できない値(value)は、プログラムの実行時の状態が仕組みとして不変になり安定する。

宣言的なスタイルを選ぶ

プログラミングのアプローチとしては、命令的なスタイルより宣言的なスタイルのほうが良い。プログラムの実行時の挙動が安定することは、良いプログラムを書くために大きなアドバンテージになる。

変数(variable)と値(value)の使い分け

ScalaやKotlinのように変数(var)と値(val)を明示的に使い分けることができる言語だと、命令的なスタイルと、宣言的なスタイルを明示的に書き分けることができる。

Javaのfinal宣言

Javaだと、final宣言を使うことで、いちおう宣言的なスタイルを表明することはできる。ただしfinal宣言した変数が参照するオブジェクトの状態が変更可能であると、簡単に命令的なプログラミングに逆戻りしてしまう。

実際にやってみると

私自身は可能な限り宣言的なスタイルでプログラミングをしたいので、ScalaやKotlinでいろいろ書いてみた時は、変数宣言(var)はまったく使わず、値宣言(val)だけで書いた。

valだらけの気持ち悪さ

そうして書いたコードを眺めてみると、valだらけで、valという宣言がほとんど意味のないノイズに近い印象をうけた。その時思ったのは、何も宣言しなければ、デフォルトで値宣言(val）になり、どうしても変数宣言(var)にしたいところだけvarを記述する、という言語であればもっとよいのになあ、と思った。

final だらけの気持ち悪さ

Javaの場合は、もっとひどい。言語仕様としては、インスタンス変数・メソッドの引数・メソッドのローカル変数・クラス変数をすべてfinal宣言にできる。

しかし、宣言的なスタイルの表明ということで徹底的にfinal宣言を書きまくると、ScalaやKotlinのval宣言だらけよりも、もっと読みにくいひどいコードになる。わかりきった場所までfinalを書くことに「いったいなんの意味があるのか」と疑問に思うくらい、final宣言が邪魔に見えてくる。

Javaの場合、final宣言を徹底しないとfinalで宣言した参照先のオブジェクトで変数を上書きされてしまう可能性が高い。標準ライブラリで用意されているList・Set・Mapなどは、変更可能なオブジェクトなので、final Map map; というような宣言をしても、実質的には、宣言的なプログラミングではなく命令的なプログラミングのままになる。つまり実行時のmapの状態は不定（不安定）なままなのだ。

しかし、そこまでfinal宣言を書くことは単純に面倒だし、書けば書くほどコードが読みにくくなるのが現実。

じゃあどうするか

ScalaやKotlinだとvalだらけになるのは、言語仕様上しかたがない。ところが、Javaの場合は、別の選択肢がある。

finalを書かないという選択肢

それはfinalを書かないという選択肢である。

もちろん、言語仕様的にはfinal宣言をしていない以上、それは再代入可能な変数であり、見た目は命令的なプログラミングそのものである。

ただしプログラミングの方針あるいは約束事として、宣言的に書く、変数の再代入はしない、ということを大前提として共有できていれば、ノイジーで面倒くさいfinal宣言をまったく書かないことも選択できる。

ScalaやKotlinのように値(val)を取り入れるた言語では、宣言的に書くにはvalを書かざるを得ない。 しかし、値(val)の仕組みがないJavaの場合、それを逆手にとって、約束として再代入不可を共有してfinalは書かないというアプローチを選択できるわけだ。

ここらへんは、ふつうのぷろぐらまのirofさんのこの記事も参考になる。

finalを付けるのをやめてみた（日々常々）

final書かずに、宣言的なプログラミングスタイルで意思統一しよう

私は、finalを書いても命令的なプログラミングのままのコードをたくさん見てきた。

final宣言の記述を強制しても、コードを書く人間の頭は命令的なプログラミングスタイルのままだということ。

そこの発想を切り替えるには、final宣言の記述のルール化よりも、変数に再代入をしない、そうすることでプログラムの挙動が安定するし、プログラムのロジックがシンプルになる、という宣言的なプログラミングスタイルの考え方とやり方を粘り強く伝え、それを共有知にすることに時間とエネルギーを使う方が費用対効果が高いと思って、日々の開発に取り組んでいる。

実際のところ、表面的にfinal宣言だらけで書いているチームよりも、final宣言は書かないが、変数には再代入をしないプログラミングスタイルを共有できているチームのほうが、読みやすく質の高いコードを生み出せている手ごたえがある。