『現場で役立つシステム設計の原則』の根幹にある原理

「現場で役立つシステム設計の原則」の「原則」って何だろう？

また、その原則をつなぎ合わせることで得られる設計は、どのような世界観を持っているのだろう？ どのような原理で説明されるのだろう？

ソフトウェアの設計に興味を持つ人間なら、そんな興味がどこからか湧き出てきてしまうもの。そんな思考の結果を記事としてアウトプットしておく。

（以下、書名を「現場で役立つ本」と略記で記載。）

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

増田さんの「現場で役立つ本」に書かれていることに私の解釈を与えて、本に書かれている方法論の世界観や原理を逆算してみた。そのようにして得られた世界観や原理を元に、「増田さんの方法論とはどのようなものか」を私なりに解説する。

以下では、「現場で役立つ本」で述べられているやり方群を「増田方法論」と呼ぶことにする。

なお、これはあくまで私による解釈だ。増田さんの言いたい本質と一致している部分があるかもしれないし、大きく違うかもしれない。この点ご承知おき願いたい。

増田方法論の根幹原理

現代のソフトウェア開発において、いかに変更に耐えていくのかということは、最も大きな悩みの種だ。したがって、ソフトウェアのソースコードにおける変更の行いやすさ＝変更容易性が、重要なトピックとなる。増田方法論は、ソースコードの変更容易性を高めることを第一の目的としている。

変更するたびに変更が大変になっていく、このソフトウェア変更の負のスパイラルから抜け出すにはどうすればよいでしょうか。

「現場で役立つシステム設計の原則」p.16

増田方法論の基本原則

増田方法論の骨格となる基本原則は、次のとおりだ。

• システムの仕様に影響を及ぼす要素は、すべてドメインレイヤーに集めよ
• ドメインレイヤーのコードを、変更が容易なソースコードとして作成せよ
• 上記2つの原則を、他の設計原則よりも優先せよ

この原則について正しく理解するためには、使われている言葉の意味内容を明確にしなければならない。最も肝となる用語は、最初にも取り上げた「変更容易性」だ。

増田方法論における「変更が容易」なソースコードとは

一口に変更容易性と言っても、定義や実現方法が一つに定められているわけではない。たとえばデータモデルにおける正規化や、歴史的なオブジェクト指向の設計原則などには、変更容易性を高める技術という側面があるだろう。増田方法論では、変更容易性を最も重要な指標として扱っているが、実は変更容易性の捉え方そのものにも特徴がある。

増田方法論における変更容易性は、次のように定義される。

ソフトウェアに変更が必要な時に、ソースコード上で変更しなければならない箇所を特定する時間の短さの度合い。および、変更作業にかかる時間の短さの度合い。

これらの時間が短いことこそ、増田方法論において「変更が容易」な状態なのだ。

ソースコードを整理整頓して、どこに何が書いてあるかわかりやすくする。それがソフトウェアの設計です。

「現場で役立つシステム設計の原則」 p.14

うまく設計されたプログラムは変更が楽で安全です。変更すべき箇所がかんたんにわかり、変更するコード量が少なく、変更の影響を狭い範囲に限定できます。

「現場で役立つシステム設計の原則」p.14,15

増田方法論における変更容易性を促進するための方法

「現場で役立つ本」には、さまざまな方法が紹介されている。それらは基本的に、増田方法論における変更容易性を促進するための方法だ。これらはざっくりと2つにまとめることができる。

• 仕様文章に現れる重要な用語をすべてクラスにする
• ビジネスドメインにおける情報構造の一般形を使う

これらを簡単にまとめておく。

仕様文章に現れる重要な用語をすべてクラスにする

仕様の文章に現れる重要な用語は、漏れなくクラスにしていく。ここで重視されるのが、数量の単位だ。数量の単位は値オブジェクトと呼ばれるパターンを使い、クラスにしていく。こうすることで、値を計算するようなメソッドにおいても、引数や戻り値にプリミティブな値ではなく、クラスを使うことができる。引数や戻り値をクラスにしておくと、メソッド内の処理の前提条件や事後条件の範囲を狭めることができる。前提条件や事後条件の範囲が狭いほど、メソッド内で考慮しなければならない事柄が減り、コードはシンプルになる。同時に、コードを変更した際の影響範囲を限定しやすくなる。結果として、コードの変更を安全に行えるようになる。

ドメインモデルの設計アプローチは、まず部品を特定し、その部品ごとに独立したクラスを設計することです。受注時のルールすべてを扱う大きなクラスは、考えないようにします。数量パッケージと同じように、与信パッケージや基本契約パッケージについても独立して設計します。

そうやって、ある程度の部品がそろってきたら、組み合わせ方を考えます。組み合わせてみながら、個々の部品を調整したり、不足している部品を追加することで、受注ルールに網羅できるだけのドメインオブジェクトが整っていきます。

「現場で役立つシステム設計の原則」p.118

ビジネスドメインにおける情報構造の一般形を使う

ビジネスドメインの情報構造は、概ね次に示す要素に当てはめることで表現できる。

• オブジェクト・・・1つの情報
• コレクションオブジェクト・・・オブジェクトの集合を表す
• 値オブジェクト・・・値や単位を表す
• 区分オブジェクト・・・区分を表す

これらの要素は互いに関係しているため、業務の仕様に登場する用語をこれらの要素に当てはめていくと、業務の概念体系が自然とツリー構造として作られていく。このツリー構造を一旦作ってしまえば、処理として記述すべき業務ロジックをどこに書けばよいのかは、比較的簡単に定められる。

書き方がよくわからない状態で、ドメインオブジェクトを設計しようとしても、時間がかかるばかりです。

その時間を省くには、ドメインオブジェクトの設計パターンを体で覚えてしまうことです。

「現場で役立つシステム設計の原則」p.124  

そして、、、

ここに挙げた基本原則や各種方法に従うことで、理想的なソースコードのツリーは、仕様に現れる用語が業務ごとに体系的に整理された状態となるはずだ。そのような状態になったソースコードのツリーでは、業務の体系をたどるようにソースコードをたどることができる。業務用語に関係した処理は、その業務用語に対応するクラス内に書かれているため、どの業務処理のコードがどのクラスに書かれているのかを、瞬時に見つけることができる。一つ一つのクラスは十分に小さく作られ、メソッドの入出力の範囲は小さく明確で、ロジックの重複もない。

かくして、ソフトウェアの変更はとても容易になる。

おわりに

このような記事を書いておいて不思議に思われるかもしれないが、私は増田方法論そのもの、および方法論の伝え方といった点で、批判的立場だ。興味のある方は、批判記事も読んでみていただきたい。

しかし、内容を正確に理解した上で、どのような立場をとるのかは各人の自由だと思う。さまざまな立場から方法論を見つめることで、有益な気付きが得られるものだと思うからだ。この記事がそのような議論の一助になれば幸いだ。