こちらの本を読んででのレポートです。

複雑な業務ロジックは「適切な境界」で分離されていれば理解しやすくなる！

…が最近の自分の持論なのですが、じゃあ「適切な境界」って何よ？ …と言われると、うまく言語化説明できない。

そんな私にたくさんヒントを与えてくれた本でした。

なかなか消化しきれていないところもあるのですが、腹落ちさせるためにもブログに落としてみます。

このブログに書いたことをまとめると・・・ 修正が大変なのはロジックが分散しているから

データとロジックをひとつのクラスにまとめるとロジックが分散しない！

じゃあWeb APIでサービス間連携するときも、データを持つほうにロジックを寄せるべき… と思ったら、そうでもない？

ソフトウェアの変更が大変なのは「設計」が悪いから （第１章より） ソフトウェアの変更は大変。 どこに何が書いてあるかを理解するまでに、調査に時間がかかる

ちょっとの修正なのに、変更すべき箇所があちこちに散らべっている

慎重に修正したのに、思わぬ副作用に苦しむ

こういった変更が大変なプログラムは以下のような特徴がある。 メソッドが長い

クラスが大きい

引数が多い

ならばリファクタリングしましょう。 わかりやすい名前を使う

目的ごとに変数を用意する

メソッドを独立させる

異なるクラスの重複したコードをなくす

狭い関心事に特化したクラスにする ここまではおそらく、ほぼ万人に受け入れられる、「当たり前のこと」ではないでしょうか。

うんうんそうだよね、と読める内容。 ところがここからじわりじわりと、人によっては「お！？」と思うような内容が書かれています。 値オブジェクト（Value Object）を用意する。基本データ型を使わない。 数量を扱うために、Quantityクラスを作り、1以上100以下の様に制約も記述する。マイナスや非常に大きな値もの取りうるintをそのまま使わない

電話番号を扱うのに、フォーマットのルールまで定めたTelephonNumberクラスを作る。Stringをそのまま使わない

値オブジェクトを作ることで、業務の用語がプログラム中に現れるため、変更の際の調査が用意になる。『業務に関係するデータとロジックを閉じ込めておくことができる』

値オブジェクトはImmutableに。1つの変数を異なる目的に使うような、変数の引き回しを防げる そんないちいちクラスを作るなんてコード量が多くなるだけ… という意見が出てきそうなところです。

実際、私が今まで仕事で見てきたプログラムでは、ここまで徹底して値オブジェクトが作られているものは見たことがありませんでした。 コレクションオブジェクトを用意する。配列やコレクションを表に出さない。 ループなど、コレクションを扱うコードは複雑になりがち。プログラムのあちこちに散らばり始めると読みにくくなる

専用のクラスに閉じ込める。例えば、List を直接表に出さないで、Customersというクラスを作り、そのインスタンス変数としてList を持つ

Immutableにするため、インスタンス変数をそのままGetterで返さない。別のコレクションを作り直して返す

コレクションに対する処理（全要素を返すとか、追加するとか、特定の条件のもののみ返すとか）は全てクラス内にメソッドとして実装 確かに、Javaでは8以降Lambda式が導入され、コレクションに対する処理の記述力が高まりましたが、だからこそ（？）複雑なStreamによる、一見するとよくわからない処理がかえって増えたようにも感じていました。

この方法にすることで、強制的に各処理に名前をつけざるを得なくなるため、可読性は高まりそうです。 一方で、慣れないと、Customers→List の構成が冗長に感じたり、

「一個のインスタンスだと思って蓋を開けたら実はリストだった。びっくりした。」

ということもありそうに感じました。