概要

関連のあるロジックが膨大なソースコードの中のあちこちに書き殴られ、散在し、追うのが大変な低凝集クラス。別名「スパゲッティコード」とも呼ばれ、無関係なロジックと絡み合い、変更を難しくしているアイツ。
そんな低凝集クラスの退治に有効な設計手法を紹介致します。

本記事の内容は ValueObjectパターンと 完全コンストラクタパターンを用いた品質向上の設計手法です。低凝集に徹底対抗するため、かなりギッチギチに設計要件を詰め込んでいます。

本設計手法による効果

• 生産性向上
• 修正漏れ低減
• クローンコード低減
• 未初期化状態の防止
• 不正値の防止
• 異なる概念の値混入抑止
• インスタンス生成の安全性向上
• リスト操作に関する複雑度低減
• 理解容易性向上
• コードのトレーサビリティ向上

よくあるダメな例

まずはValueObjectを用いていない、架空のコードを例に説明致します。
ここではなるべく分かりやすいように、今ホットな消費税を例にします。

税込み金額と消費税率を単に格納するだけの契約金額クラスがあったとします。
(※以下サンプルコードはC#にて記述)

/// <summary>契約金額</summary>publicclassContractAmount{publicintAmountIncludingTax;publicdecimalSalesTaxRate;}

当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。

/// <summary>契約コントローラー</summary>publicclassContractController{privateContractAmount_contractAmount;/// <summary>税込金額を計算する。</summary>/// <param name="amountExcludingTax">税別金額。</param>/// <param name="salesTaxRate">消費税率。</param>/// <returns>税込金額。</returns>publicintCalculateAmountIncludingTax(intamountExcludingTax,decimalsalesTaxRate){return(int)(amountExcludingTax*(1.0m+salesTaxRate));}/// <summary>契約締結する。</summary>publicvoidConclude(){// 省略intamountIncludingTax=CalculateAmountIncludingTax(amountExcludingTax,salesTaxRate);_contractAmount=newContractAmount();_contractAmount.AmountIncludingTax=amountIncludingTax;_contractAmount.SalesTaxRate=salesTaxRate;// 省略}}

クラス図にすると以下の関係となります。

ごく小規模なアプリであれば、この設計は特に問題にはならないでしょう。しかし大規模になるにつれ、この設計は様々な問題をはらむようになってきます。
どんな問題が起こるのか順番に見ていきましょう。

課題

課題1：低凝集

アプリが大きくなってきても、相変わらずデータを保持する場所(データクラス)とデータを操作するロジックを別々箇所に実装しているとどうなるでしょうか。
例えば下記クラス図のように、消費税関連の演算メソッドが様々なContollerに定義されている場合はどうでしょう。

消費税関連のロジックが様々な箇所に分散してしまっていますね。
このように関連するデータやロジック同士が分散してしまっているのを 低凝集と言います。低凝集なコードではどんな課題が発生するのか以下に列挙します。

課題1-1：生産性低下

上図はまだなんとか関連を把握できますが、これが何千何万行のソースコードに分散すると、全て探し出すだけで一苦労で、時間と精神力をいたずらに消耗することになります。

課題1-2：修正漏れ

また、関連コードを全て探し出せるとは限りません。漏れが生じる可能性もあります。仮に洗い出しに漏れが生じると、消費税関連のバグが発生します。

課題1-3：コードクローン（コピペコード）

あらゆる箇所に分散していると把握が困難になります。例えば既に実装済みの機能があるのに、別の開発メンバに「この機能は未実装だ」と誤解される恐れがあり、同じようなロジックが至るところに複数実装されることになります。意図せずコードクローンが量産されるこになります。

課題2：不正状態

課題1で挙げた低凝集に付随して、データクラスContractAmountは以下に示す不正状態へ陥る可能性があります。

課題2-1：未初期化状態（生焼けオブジェクト）

ContractAmountクラスは、newされた直後はインスタンス変数の初期化が済んでいません。ContractControllerでConclude()が実行されるまでは不完全な状態、即ち不正状態です。

Conclude()がコールされる前にContractAmountインスタンスが何かに利用されるとバグになります。
このように初期化が済んでおらず、使い物になってないオブジェクト、または未初期化状態を発生しうるオブジェクトを、アンチパターン 生焼けオブジェクトと言います。

課題2-2：不正値の混入

その他、消費税率に負数を代入するなど、不正値を与えることも容易に出来てしまいます。

varcontractAmount=newContractAmount();contractAmount.SalesTaxRate=-0.10m;

課題まとめ

以上、低凝集であることにより以下の課題が発生します。

• 生産性低下
• 修正漏れ
• コードクローン
• 未初期化状態（生焼けオブジェクト）
• 不正値混入

単にデータを保持するだけの、なんら処理ロジックを持たない データクラスは低凝集です。上記種々の問題を誘発させる アンチパターン「ドメインモデル貧血症」であり、 悪なのです(※CQRSパターンのQuery層でDTOとして利用するのは別の話)。
こうした問題を発生させないための設計方法が、これから紹介する ValueObject、及び 完全コンストラクタです。

ValueObject

ValueObjectとはデータのラッパーであり、正確には

• (原則的に)1個のインスタンス変数
• インスタンス変数を初期化するコンストラクタ
• インスタンス変数を正常に操作することを保証したメソッド

から構成されるクラスです。

値を単なる変数として実装するのではなく、クラスというひとつの型の単位として扱う、という考えに基づきます。
では税抜き金額をValueObjectとして扱うことを例に考えてみます。

/// <summary>税抜き金額</summary>publicclassAmountExcludingTax{privateint_amount;publicAmountExcludingTax(intamount){// 初期値はコンストラクタで与える_amount=amount;}}// 税抜き金額1000円varamountExcludingTax=newAmountExcludingTax(1000);

まずは基本形。ここから全てがスタートします。
税抜き金額の値をコンストラクタで与え、インスタンス変数に格納します。
しかしここまではアンチパターンである データクラスとあまり変わらないように見えますね。
事実、以下のように不正値を混入可能です。

// 負の金額、即ち不正値を代入できてしまう。varamountExcludingTax=newAmountExcludingTax(-100);

どうすれば良いでしょうか。これを解決するのが 完全コンストラクタです。

完全コンストラクタ

オブジェクトを「 newした時点で正しく利用可能な、即ち完全体」となるよう適切な初期化ロジックをコンストラクタに実装する方法です。
税抜き金額のあるべき姿、要件を考えてみましょう。

• 0以上の整数であること

となりますね。この要件を満たすもののみインスタンス変数に格納するようフィルタリングすれば良いのです。要件未達の値は例外を投げるよう実装します。

/// <summary>税抜き金額</summary>publicclassAmountExcludingTax{privateint_amount;publicAmountExcludingTax(intamount){// コンストラクタで不正値を除外if(!IsValid(amount)){thrownewArgumentOutOfRangeException();}_amount=amount;}// 税抜き金額のバリデーションを用意privatestaticboolIsValid(intamount){// 正常値の要件を記述return0<=amount;}}

これで正常値のみインスタンス変数に格納できるようになりました。

生まれながらにして完全体

完全コンストラクタは更に利点があります。不正値が渡されるとコンストラクタで例外をスローするので、 不正値を持ったAmountExcludingTaxのインスタンスが存在できなくなります。常に安全で正常なインスタンスのみが存在し、利用できるようになります。
完全コンストラクタで設計したクラスのインスタンスは、 生まれながらにして完全体なのです。誕生した瞬間 セル完全体なのです。

一方不正値が混入すると例外をスローしAmountExcludingTaxのインスタンスが存在できなくなくなるので、 不完全なセル第１形態や第２形態は 誕生前に即死することになります。これはスゴイ！！

ValueObjectと完全コンストラクタを利用せずに変数に対してバリデーションをかけることも当然可能ですが、ただの変数の場合、後から不正値を再代入できてしまう点において劣ります。

setterを用意しない

再代入を容易に許すと折角完全コンストラクタで確保した安全かあっさり崩れてしまいます。従ってsetterを用意してはいけません。
getterのみ用意するようにしましょう(※より良い設計ではgetterすらない方が良い、後述)。

/// <summary>税抜き金額</summary>publicclassAmountExcludingTax{privateint_amount;// getterのみ用意する(※より良い設計ではgetterすら用意しない)publicintValue{get{return_amount;}}

immutable(不変)にする

内部のインスタンス変数が変更可能な状態にあると、並列処理などにおいていつの間にか値がすり替わっているなど意図しない副作用が発生する可能性があります。より安全に倒すため、ValueObjectは不変にしましょう。インスタンス変数にreadonly(Javaでいうfinal修飾子)を付与します。これでコンストラクタで初期化以後、変更できなくなります。

/// <summary>税抜き金額</summary>publicclassAmountExcludingTax{// これでコンストラクタ以後書き換えられなくなり、不変となる。privatereadonlyint_amount;

【！超重要！】許可された操作のみメソッド化する

さて、不変にしたところで値を変更したい場合どうすればいいでしょう。
例えば税抜き金額同士で加算したいケースがよくあるでしょう。その場合、加算結果を格納した新たなValueObjectのインスタンスを生成するよう設計します。ここでは加算メソッドAddを用意してみました。

/// <summary>税抜き金額</summary>publicclassAmountExcludingTax{// 省略publicAmountExcludingTaxAdd(AmountExcludingTaxamountExcludingTax){// 税抜き金額同士を加算する。// 引数には同じAmountExcludingTaxだけ渡せるよう設計。returnnewAmountExcludingTax(_amount+amountExcludingTax._amount);}// 省略}// 使用例varamount1=newAmountExcludingTax(100);varamount2=newAmountExcludingTax(10);vartotal=amount1.Add(amount2);Console.WriteLine(total.Value);// 110が出力される

これにより元のインスタンスの不変を維持したまま変更値を用意可能です。

但し要注意です。
金額同士の加算は用途上考えられますが、乗算はないはずです。税抜き金額がValueObjectではなく単なるローカル変数である場合を考えてみて下さい。乗算どころかどんな計算でも制約なく出来てしまいます。
金額ならば加算や減算だけなど、業務概念的に許可された操作だけをメソッドとして公開することで、不正な演算を許さない、頑強な設計となります。
この設計思想からするとgetterで値取得可能な構造は、取得先の外部で勝手な演算が出来てしまうので、可能な限りgetterを実装しないのが望ましい姿です。但し、getterがないとUI表示や永続化の際値が取れなくなるので、バランス取りが難しいところです。

全てのクラスに備わる「自己防衛責務」

「詳細な初期化処理や事前準備をしないと使い物にならない」……あなたはこんなクラスやメソッドを使いたいと思いますか？
そもそもの話として、ソフトウェアはメソッド、クラス、モジュール、どの粒度でも、それ 自体が単体でバグがなく いつでも安全に利用できる品質が求められます。
クラスも各々が他に依存することなく単体で安全に利用できるよう設計されている必要があります。他のクラスに初期化して貰ったり、バリデートして貰っているようなクラスは未熟なクラスです。 自分の身は自分で守らせる。 自己防衛責務を 全てクラスが備える、という考え方がソフトウェア品質を考える上で重要です。完全コンストラクタはその方針を設計に落としたもののひとつです。
構成部品であるクラスひとつひとつが品質的に完結していることにより、ソフトウェア全体の品質が向上するのです。

課題は解決されたか？

ValueObjectと完全コンストラクタの基本は以上になります。
さて、この記事の冒頭で低凝集による種々の課題を列挙しましたが、解決されたのでしょうか？
今一度AmountExcludingTaxのクラス図とソースコードを見てみましょう。

/// <summary>税抜き金額</summary>publicclassAmountExcludingTax{privatereadonlyint_amount;publicintValue{get{return_amount;}}/// <summary>コンストラクタ</summary>/// <param name="amount">税抜き金額</param>publicAmountExcludingTax(intamount){if(!IsValid(amount)){thrownewArgumentOutOfRangeException();}_amount=amount;}/// <summary>税抜き金額を加算する</summary>/// <param name="amountExcludingTax">税抜き金額</param>/// <returns>税抜き金額</returns>publicAmountExcludingTaxAdd(AmountExcludingTaxamountExcludingTax){returnnewAmountExcludingTax(_amount+amountExcludingTax._amount);}/// <summary>有効な税抜き金額であるかを返す</summary>/// <param name="amount">税抜き金額</param>/// <returns>有効な場合true</returns>privatestaticboolIsValid(intamount){return0<=amount;}}

税抜き金額の単なるデータだけでなく、許容値や演算メソッド(Add)など、関連するロジックが凝集しているのがお分かり頂けますでしょうか。このようにデータとそれを処理するロジックが分散せず、一箇所に集められカプセル化されているのを 高凝集と呼びます。
では低凝集で生じる課題がどう解決されたか説明します。

更に発展応用させる

以上がValueObjectの基本となります。上記だけでもかなりの設計要件が登場しましたが、更に様々なパターンに対応し応用できるよう発展させていきます。

以下では、 税込み金額の計算を題材に、ValueObjectパターンに関し更に深堀りしていきます。ぶっちゃけ税込み金額は「税抜き金額 x 消費税率」で算出できてしまうのですが、消費税率の適用ルール周りには様々な要件や業務知識が存在するので、そうした概念を踏まえた上で堅牢な設計をしていきます。

消費税率をValueObject化してみる

まずは消費税率をValueObjectとして設計してみます。
とりあえず税抜き金額AmountExcludingTaxと同様に、初期値をコンストラクタで与える形で作ってみます。

/// <summary>消費税率</summary>publicclassSalesTaxRate{privatereadonlydecimal_rate;publicSalesTaxRate(decimalrate){if(!IsValid(rate)){thrownewArgumentOutOfRangeException();}_rate=rate;}privatestaticboolIsValid(decimalrate){return0<=rate;}}

一応それらしいものができました。…ですがこれで良いのでしょうか？

再燃する課題…低凝集

消費税率の値は、商品を購入した日時によって決まります。また、その値も固定です(例えば2019/10/01より10%)。ですが、この設計ではコンストラクタから任意の税率を代入できてしまいますし、そもそも税率を決定するロジックが存在しません。そのロジックはどこに実装されるのでしょうか。前の例のようにControllerクラスに実装されるのでしょうか。するとまた低凝集な設計になり、生産性低下など様々な問題を生み出してしまいます。

凝集しよう － 完全コンストラクタのおさらい

振り返ってみましょう。「 newした段階で使い物になるようにコンストラクタ内で初期化処理を完結する」というのが完全コンストラクタの主旨です。つまり、 日付により消費税率を決めるロジックを消費税率クラスのコンストラクタ内に定義するのが自然、と考えられます。

消費税率周りのドメイン分析

ではどのように消費税率の値が決められるのか、一度消費税率に関する業務知識を確認してみましょう。

• 消費税は施行日がある。法によって定められた 消費税施行日以降に 当該消費税率が適用される。
• 売買契約が締結した時点の消費税率を適用する。
• つまり、 契約日が所定の 消費税施行日以降である場合、 当該税率が適用される。
• （※経過措置など難しい概念もあるが今回は割愛）

ここでいくつか重要そうな概念が洗い出されました。

• 消費税施行日（固定）
• 消費税率（固定）
• 契約日（任意）

つまり契約日が決まってしまえば、あとは消費税施行日と照らし合わせて消費税率が決まる仕組みですね。「消費税率は契約日により一意に決まる」、ということが分かりました。
つまり、

• コンストラクタで契約日を受け取る。
• コンストラクタ内で契約日と消費税施行日を比較して消費税率を決定する。
• 得られた消費税率の値をインスタンス変数へ格納する。

というロジックになれば良さそうです。

/// <summary>消費税率</summary>publicclassSalesTaxRate{privatereadonlydecimal_rate;publicSalesTaxRate(DateTimecontractDate){// 省略するがここで契約日と消費税施行日とを比較し、消費税率を決定する。_rate=// 決定した税率値を代入}

税抜き金額AmountExcludingTaxは、金額値をコンストラクタで受け取っていました。それはUIから任意金額値を入力するユースケースから考えても自然です。一方で、消費税率クラスのようにコンストラクタ引数の値が同一概念の値とは限りません。
何に依存してその値が決定するのか、しっかりドメイン分析することが肝要です。

契約日の扱い

ところで消費税率クラスのコンストラクタ引数となる契約日は、ただのDateTime型で良いのでしょうか？ものによりますが、アプリで扱われる日時は、例えば生年月日、注文日など多種にわたるでしょう。例えば以下のようなコードは許されるのでしょうか。

DateTimecontractDate=birthday;varsalesTaxRate=newSalesTaxRate(contractDate);

契約日に誕生日を代入してしまっており、どう見てもバグとなりますね。
ここでも役立つのがValueObjectです。
契約日をValueObjectとして設計し、コンストラクタ引数を契約日の型にすれば、異なる概念の値が混入してしまうのを防ぐことができます。

/// <summary>契約日</summary>publicclassContractDate{privatereadonlyDateTime_date;// 省略}

/// <summary>消費税率</summary>publicclassSalesTaxRate{privatereadonlydecimal_rate;publicSalesTaxRate(ContractDatecontractDate){// 省略

varbirthday=newBirthday(newDateTime(1990,4,2));varsalesTaxRate=newSalesTaxRate(birthday);// 型が異なるのでコンパイルが通らない

あらゆる値をValueObjectとして設計する

ドメイン駆動設計のようにドメイン層を設ける設計であれば、ドメイン層では どんな値もなるべく全てValueObjectで扱った方が良いです。そして プリミティブな型ではなくValueObject型でやり取りし、 全てのValueObjectで異なる型の代入を弾く設計実装すれば、 異なる概念の値混入に対して非常に強固な作りになります。
ちなみに私の以前の開発現場では、こうした異なる概念の値混入によるバグがたびたび発生していました。一度に多くのパラメータを取り扱うユースケースで特に起こっていました。こうしたつまらないバグにつまづかないよう、こまめにValueObject化することが肝要だと考えます。

ここまでの検討により、インターフェースはだいたい決まりました。
一度クラス図を起こします。

このクラス構成に基づき、設計実装の細部を詰めていきます。

契約日クラス

契約日クラスを設計していきます。
初期値を決めたいのですが、コンストラクタ引数で初期値となるDateTime型を渡してよいのでしょうか？低凝集の不安がありますね。一度ドメイン分析しましょう。

• 売買契約が締結した日時である。
• 永続化対象である。(※本来ドメイン分析で考慮すべきことではない)

まず締結日時ですが、締結したときに任意DateTimeを利用側から与えられるのではなく、契約日クラス側で決めてしまった方が良いですね。

/// <summary>契約日</summary>publicclassContractDate{privatereadonlyDateTime_date;publicContractDate(){_date=DateTime.Now;}}

また、契約日は永続化対象なので、リポジトリから読み出した値を格納できるようにクチを設けておく必要があります。

/// <summary>契約日</summary>publicclassContractDate{privatereadonlyDateTime_date;// 契約締結時に呼び出す用publicContractDate(){_date=DateTime.Now;}// リポジトリからの読み出し用publicContractDate(DateTimedate){_date=date;}}

ところでコンストラクタが複数あります。コメントで説明はしていますが、利用側からはどちらのコンストラクタが何の用途か非常に分かりにくいものなってしまいます。どうすれば良いのでしょうか。

Factoryメソッド＋privateコンストラクタ

こういう場合、用途ごとのFactoryメソッドを用意します。各Factoryメソッドには、用途に相応しい命名をします。

/// <summary>契約日</summary>publicclassContractDate{privatereadonlyDateTime_date;publicDateTimeValue{get{return_date;}}// 制約を無視した勝手なインスタンス生成を利用側にされないようprivateにするprivateContractDate(DateTimedate){_date=date;}// 契約締結時に呼び出す用publicstaticContractDateConclude(){returnnewContractDate(DateTime.Now);}// リポジトリからの読み出し用// リポジトリ以外からの生成に利用されないようinternalにするinternalstaticContractDateReconstruct(DateTimedate){returnnewContractDate(date);}}

そしてコンストラクタはprivateにします。こうすることで契約日ContractDateの 生成方法を用途別に縛ることができます。 クラス設計者の予想だにしない使われ方をさせないことも、安全性を高める上で重要です。また、リポジトリから読み出した場合に用いられるReconstruct()はinternalにすることでパッケージ内のみアクセス可能になり、アプリ層やView層などからコールされることがなくなります。

消費税率適用ルールの設計

先ほど「消費税率を決定するロジックを消費税率クラスのコンストラクタに定義する」と書きました。しかし「消費税施行日」など様々な概念が絡んでいそうです。単純に実装しただけでは 複雑度が増大し、保守が難しくなりそうなので、小分けにしてボトムアップで考えていくことにします。

以下のようなロジックを元に考えてみます。

• 消費税施行日とその適用税率をリストで持っておく。
• 消費税施行日が最新のものから順に契約日と比較する。契約日が消費税施行日以降であれば、その税率を適用する。

消費税クラス

消費税に関しては、施行日と税率がセットになっているので、一緒にしてしまって良さそうです。

/// <summary>消費税</summary>internalclassSalesTax{/// <summary>施行日</summary>privatereadonlyDateTime_enforcementDate;/// <summary>税率</summary>privatereadonlydecimal_rate;internalSalesTax(DateTimeenforcementDate,decimalrate){if(!IsValidRate(rate)){thrownewArgumentOutOfRangeException();}_enforcementDate=enforcementDate;_rate=rate;}privatestaticboolIsValidRate(decimalrate){return0m<=rate;}}

名前がカブった？？

ちょっと話が外れますが、先ほど消費税率クラスをSalesTaxRateと命名しました。一方、上述の消費税クラス、インスタンス変数に_rateがいます。SalesTax._rateとSalesTaxRate、なんだか紛らわしいですね。どうも概念的に微妙に違っていそうです。命名をブラッシュアップしてみましょう。
そもそも消費税率クラスは一体何なのでしょうか。

/// <summary>消費税率</summary>publicclassSalesTaxRate{privatereadonlydecimal_rate;// コンストラクタで契約日を受け取るpublicSalesTaxRate(ContractDatecontractDate){// ここで契約日と消費税施行日とを比較し、消費税率を決定する。

契約日により税率を決定しています。つまり完全コンストラクタの設計思想に基づけば、これは「契約日に 適用された税率」なのです。すると冒頭の消費税率クラスは「 適用された消費税率」と名付けた方がより適切ですね。SalesTaxRateからAppliedSalesTaxRateへ 命名をブラッシュアップします。

/// <summary>適用された消費税率</summary>publicclassAppliedSalesTaxRate{privatereadonlydecimal_rate;// コンストラクタで契約日を受け取るpublicAppliedSalesTaxRate(ContractDatecontractDate){// ここで契約日と消費税施行日とを比較し、消費税率を決定する。

完全コンストラクタで設計したクラスの名前は「○○された△△」、「〜ed△△」というように、何かによって完成品 となった命名をするのが望ましいです。

消費税適用ルールクラス

消費税クラスSalesTaxを用いて、消費税適用ルールSalesTaxApplyRuleを設計します。
上述の通り、「消費税の施行日と税率を消費税クラスとしてリストで持っておき、施行日が最新のものから順番に契約日と比較して、契約日が施行日以降であればその税率を適用する」としましょう。
下記コードのようにコンストラクタでリスト生成して、ApplyRule()で適用税率を返します。

/// <summary>消費税適用ルール</summary>internalclassSalesTaxApplyRule{privatereadonlyList<SalesTax>_salesTaxes;internalSalesTaxApplyRule(){_salesTaxes=newList<SalesTax>();// 最新の施行日から順に格納すること。// (開発者が順番を気にしなくても良いように設計するのがホントは望ましい)_salesTaxes.Add(newSalesTax(enforcementDate:newDateTime(2019,10,1),rate:0.10m));_salesTaxes.Add(newSalesTax(enforcementDate:newDateTime(2014,4,1),rate:0.08m));_salesTaxes.Add(newSalesTax(enforcementDate:newDateTime(1997,4,1),rate:0.05m));_salesTaxes.Add(newSalesTax(enforcementDate:newDateTime(1989,4,1),rate:0.03m));}internaldecimalApplyRule(ContractDatecontractDate){varcorresponded=_salesTaxes.Find(tax=>tax.EnforcementDate<=contractDate.Value);returncorresponded!=null?corresponded.Rate:0.00m;}}

ちなみにこのSalesTaxApplyRuleの設計はValueObjectパターンの亜種で、リストに対しての業務ロジックをカプセル化する設計パターン「 ファーストクラスコレクション」といいます。リスト操作は兎角ネスト構造になりがちでコードが 複雑化しやすいので、是非覚えて下さい。

「適用された消費税率」クラスへ組み込み

ここまでくれば税適用ルールSalesTaxApplyRuleをAppliedSalesTaxRateへ組み込むことができますね。

/// <summary>適用された消費税率</summary>publicclassAppliedSalesTaxRate{// 税適用ルールは1つあれば良く、複数生成させないようstatic readonlyとする。privatestaticreadonlySalesTaxApplyRule_salesTaxApplyRule=newSalesTaxApplyRule();privatereadonlydecimal_rate;publicdecimalValue{get{return_rate;}}publicAppliedSalesTaxRate(ContractDatecontractDate){_rate=_salesTaxApplyRule.ApplyRule(contractDate);}}

税込み金額クラス

最後に税込み金額クラスです。
これもValueObject+完全コンストラクタで設計します。
税抜き金額クラスと適用された消費税率クラスのインスタンスを渡し、税込み金額を計算し格納します。

/// <summary>税込金額</summary>publicclassAmountIncludingTax{privatereadonlyint_amount;publicintValue{get{return_amount;}}publicAmountIncludingTax(AmountExcludingTaxamountExcludingTax,AppliedSalesTaxRateappliedSalesTaxRate){_amount=(int)(amountExcludingTax.Value*(1m+appliedSalesTaxRate.Value));}}

これで目標である税込み金額クラスを設計できました。

おさらい

最終的なクラス図とソースコードです。

/// <summary>税抜き金額</summary>publicclassAmountExcludingTax{privatereadonlyint_amount;publicintValue{get{return_amount;}}/// <summary>コンストラクタ</summary>/// <param name="amount">税抜き金額</param>publicAmountExcludingTax(intamount){if(!IsValid(amount)){thrownewArgumentOutOfRangeException();}_amount=amount;}/// <summary>税抜き金額を加算する</summary>/// <param name="amountExcludingTax">税抜き金額</param>/// <returns>税抜き金額</returns>publicAmountExcludingTaxAdd(AmountExcludingTaxamountExcludingTax){returnnewAmountExcludingTax(_amount+amountExcludingTax._amount);}/// <summary>有効な税抜き金額であるかを返す</summary>/// <param name="amount">税抜き金額</param>/// <returns>有効な場合true</returns>privatestaticboolIsValid(intamount){return0<=amount;}}

/// <summary>契約日</summary>publicclassContractDate{privatereadonlyDateTime_date;publicDateTimeValue{get{return_date;}}/// <summary>コンストラクタ</summary>/// <param name="date">契約日</param>/// <remarks>制約を無視した勝手なインスタンス生成を利用側にされないようprivateにしている。</remarks>privateContractDate(DateTimedate){_date=date;}/// <summary>契約締結時に呼び出す。</summary>/// <returns>契約日</returns>publicstaticContractDateConclude(){returnnewContractDate(DateTime.Now);}/// <summary>リポジトリから読み出した時に呼び出す。</summary>/// <param name="date">リポジトリから読み出した契約日</param>/// <returns>契約日</returns>/// <remarks>リポジトリ以外からの生成に利用されないようinternalにしている。</remarks>internalstaticContractDateReconstruct(DateTimedate){returnnewContractDate(date);}}

/// <summary>消費税</summary>internalclassSalesTax{/// <summary>施行日</summary>internalreadonlyDateTimeEnforcementDate;/// <summary>税率</summary>internalreadonlydecimalRate;/// <summary>消費税</summary>/// <param name="enforcementDate">施行日</param>/// <param name="rate">税率</param>internalSalesTax(DateTimeenforcementDate,decimalrate){if(!IsValidRate(rate)){thrownewArgumentOutOfRangeException();}EnforcementDate=enforcementDate;Rate=rate;}/// <summary>有効な税率かどうかを返す</summary>/// <param name="rate">税率</param>/// <returns>有効な場合true</returns>privatestaticboolIsValidRate(decimalrate){return0m<=rate;}}

/// <summary>消費税適用ルール</summary>internalclassSalesTaxApplyRule{privatereadonlyList<SalesTax>_salesTaxes;internalSalesTaxApplyRule(){_salesTaxes=newList<SalesTax>();// 最新の施行日から順に格納すること。// (開発者が順番を気にしなくても良いように設計するのがホントは望ましい)_salesTaxes.Add(newSalesTax(enforcementDate:newDateTime(2019,10,1),rate:0.10m));_salesTaxes.Add(newSalesTax(enforcementDate:newDateTime(2014,4,1),rate:0.08m));_salesTaxes.Add(newSalesTax(enforcementDate:newDateTime(1997,4,1),rate:0.05m));_salesTaxes.Add(newSalesTax(enforcementDate:newDateTime(1989,4,1),rate:0.03m));}/// <summary>消費税ルールを適用する</summary>/// <param name="contractDate">契約日</param>/// <returns>適用された消費税率</returns>internaldecimalApplyRule(ContractDatecontractDate){varcorresponded=_salesTaxes.Find(tax=>tax.EnforcementDate<=contractDate.Value);returncorresponded!=null?corresponded.Rate:0.00m;}}

/// <summary>適用された消費税率</summary>publicclassAppliedSalesTaxRate{privatestaticreadonlySalesTaxApplyRule_salesTaxApplyRule=newSalesTaxApplyRule();privatereadonlydecimal_rate;publicdecimalValue{get{return_rate;}}/// <summary>コンストラクタ</summary>/// <param name="contractDate">契約日</param>publicAppliedSalesTaxRate(ContractDatecontractDate){_rate=_salesTaxApplyRule.ApplyRule(contractDate);}}

/// <summary>税込金額</summary>publicclassAmountIncludingTax{privatereadonlyint_amount;publicintValue{get{return_amount;}}/// <summary>コンストラクタ</summary>/// <param name="amountExcludingTax">税抜き金額</param>/// <param name="appliedSalesTaxRate">適用された消費税率</param>publicAmountIncludingTax(AmountExcludingTaxamountExcludingTax,AppliedSalesTaxRateappliedSalesTaxRate){_amount=(int)(amountExcludingTax.Value*(1m+appliedSalesTaxRate.Value));}}

消費税の計算に関して、全て ValueObject(及びその亜種)+完全コンストラクタで設計できました。
丁寧すぎるほど丁寧に設計しましたが、これらクラス図やソースコードをご覧になってどうでしょう、カンの良い方は以下4点に気づいたのではと思います。

• 業務概念が見える化されている
• クラスがその業務概念を説明している
• クラスが小さい
• internal(Javaでいうpackage private)の活用

それぞれ説明していきます。

業務概念が見える化されている

業務概念がひとつひとつクラス化されているため、どんな業務概念を取り扱っているのか見える化されています。
仮にこれがクラス化されていないことを想像してみて下さい。何千何万行ものソースコードの深い深い海の中のテキトーな変数として埋もれてしまい、 デバッグや仕様変更時のコード分析で多大な労苦を味わうことになるでしょう。

クラスがその業務概念を説明している

業務概念の名を冠したクラスひとつひとつが、その業務概念や仕様を説明するようにロジックが組まれています。このように、 クラス：業務概念：業務ロジック＝１：１：１となるように設計することが肝要です。
国語辞典を思い出してみて下さい。例えば「消費税」を引くと「消費に対して課される租税」と出てきます。それと同じように、ValueObjectのように業務概念を表したクラスには、「○○とは△△である」のように、 その言葉の定義を表すようロジックを実装しましょう。 理解容易性が格段に向上します。まさに 名は体を表すです。

クラスが小さい

ちゃんとドメイン分析してこまめに業務概念をクラス化すると、ひとつひとつのクラスが数十行程度の小さなものになります。
テスト容易性が向上し、安全品質が更に堅牢になります。
また、「 チャンク」でググると分かるかと思いますが、普通の人間が一度に知覚可能な概念の個数は 4±1個だとされています。クラスを小さくし、 そのクラスに登場する概念が4±1個以内に設計することにより、やはり 理解容易性の向上に貢献します。

こうして設計されたプログラムは、 トレーサビリティが向上します。 どこに何が実装されてあるのか迅速に発見することができるようになります。
例えば、消費税法では「経過措置」という概念がありますが、今回の設計では考慮されていません。「消費税率の適用には『経過措置』も考慮しなければならない。消費税適用ルールが定義されるコードはどこだ！？」という事態が発生したとします。「業務概念が全てクラスとして設計されていること」が前提となっていれば、何千何万行ものソースコードを舐める必要がなく、クラス一覧から消費税適用ルールであるSalesTaxApplyRuleクラスを見つけ出せばよいことになります。また、ルールロジックが他のクラスに実装されておらず、SalesTaxApplyRuleクラス内に閉じているので、SalesTaxApplyRuleクラスだけを経過措置に関してロジック変更すれば良いことになります。変更が高速化し、 生産性が向上します。

internal(Javaでいうpackage private)の使用

税抜き金額AmountExcludingTaxや契約日ContractDateはView層での表示が想定されるため、可視性はpublicで設計しています。一方、消費税SalesTaxや消費税適用ルールSalesTaxApplyRuleは外部からアクセスされる必要性がないため、アクセスがパッケージ内だけで閉じるようinternalで設計しています。
何でもかんでもpublicで定義してるのをプログラミング入門書で頻繁に見受けられますが、よく考えずに真似してしまうとpublic定義されたクラスはあらゆるクラスと関係し始めて影響範囲が拡大し、低凝集密結合を誘発する大きな要因となります。
パッケージの粒度設計も然ることながら、クラスの可視性は基本的にinternalで設計し、パッケージ外に本当に公開が必要なクラスのみ、publicとして設計しましょう。(※なお、C#言語仕様では、クラスのアクセス修飾子を省略するとinternalになります。この意味をよく考えてみましょう。)

まとめ

ValueObject + 完全コンストラクタ　設計要件

本記事の手法よる効果

• 生産性向上
• 修正漏れ低減
• クローンコード低減
• 未初期化状態の防止
• 不正値の防止
• 異なる概念の値混入抑止
• インスタンス生成の安全性向上
• リスト操作に関する複雑度低減
• 理解容易性向上
• コードのトレーサビリティ向上

基本ほど遠い道のり、一歩ずつ極めていきませんか

ValueObjectは1個たかだか数十行程度の規模ですが、大真面目にやろうとするといくつもの要件を満たすよう設計する必要があります。不慣れな方にとって、これら全てを満たすのはかなり骨の折れることになるでしょう。
ですがValueObjectにはソフトウェア設計の基本が詰まっていると私は思っています。基本をひとつずつ踏み固め、一歩ずつ極めていくことで、高品質で高い開発生産性に繋がっていくことでしょう。