連載目次
第1章：小さくまとめてわかりやすくする →本記事
第2章：場合分けのロジックを整理する
第3章：業務ロジックをわかりやすく整理する（公開予定）
はじめに
この記事は、増田亨さんの著書「現場で役立つシステム設計の原則」の、主に私自身へ向けた読書備忘録です。（追ってサンプルコードも追加予定）
とても素晴らしい本だと思うので、興味を持たれた方はぜひ読んでみてください。
リンクは記事の最後にあります。
本章の概要
第1章：小さくまとめてわかりやすくする
変更が楽で安全なプログラムを書くための第一歩として、
ソースコードの整理整頓の基本を学びます。
覚えておきたいキーワード
今後、理解を深めたいと感じたキーワードのメモです。
ドメイン駆動設計については初心者なので、基本的なものが多いかもしれません。
破壊的代入
1つの変数を使いまわして代入を繰り返すこと。再代入。
破壊的代入はプログラム変更の副作用を起こしやすいため、極力避けた方がコードが安定します。
値オブジェクト（Value Object）
値を扱うための専用クラスを作るやり方。
金額、数量、年月、電話番号など業務上の名前や用語をそのままに、小さなクラスを定義して、長さや形式などのルールは、値オブジェクト内に明示的に定義します。
こうする事で、正しい値を扱うことが保証されます。
単純に String や int 型の変数を定義するだけでは、業務の関心事にそぐわない異常な値も設定できてしまうため。
完全コンストラクタ
オブジェクトの生成時に、オブジェクトの状態が完全に決定され、それ以降は不変とする設計パターン。
setter メソッドは作らず、別の値が必要になったら、別のオブジェクトを作成します。
値オブジェクトとセットで覚えておきたいキーワードです。
本章の個人的共感ポイント
本章のなかで特に共感したポイントのメモです。
開発現場で取り組んでみたい度合いを「★」の数で表現してみました。
わかりやすい名前を使う
名前のわかりやすさは、プログラムの読みやすさ／読みにくさに直結します。名前があいまいだったり、名前と内容が一致していないプログラムは読むのに苦労します。（p17）
取り組みたい度：★★★★★
クラス名やメソッド名は下手なものを使えないけれど、変数名（特にローカル変数）は、実装者の個性が現れやすいように感じます。
本文の例にあるような1文字の変数名（int a;）はさすがに見たことがありませんが、ロジック全体を読まないと、変数の内容が読み取れないような名前は時々見かけます。
特に「業務で使っている言葉をそのまま」使うべき、という点には非常に共感。日本語の業務用語を無理に英語に訳して、意味が分かりづらくなった経験が何度もあります。
メソッドは短く、クラスは小さく
変更に苦しむのは、いつでも長いメソッドと大きなクラスです。（中略）コードを「短いメソッド」と「小さなクラス」に小分けして整理するのが、変更を楽で安全にする設計の基本です。（p27）
取り組みたい度：★★★★★
本章の冒頭にある「クラスは最初から大きかったわけではありません」という言葉が、特に印象的でした。ほんの少しの修正や機能追加が積み重なって、メソッドの数が増え、気がつけば巨大なクラスに...という経験は誰でもあるのではないでしょうか。
設計は初期段階で終わるものではなく、常に改善を重ねていくべき（メソッドの抽出やクラスの分割も積極的に行なう）というのは、個人的には大きな気づきでした。
小さいところから始めないと難しいかな、という思いから★4つ。
「値」を扱うための専用のクラスを作る
値の種類ごとに専用の型を用意するとコードが安定し、コードの意図が明確になります。（p32）
取り組みたい度：★★★★★
ドメイン駆動設計における「値オブジェクト（Value Object）」という実装パターンについての説明。自分でデータの種類ごとに専用の型を作ってしまう、という発想が全くなかったので、目からウロコな内容でした。
また、値オブジェクトは不変（とするもの）なので、ロジックの途中で思わず値が変更されてしまう、という不具合が起こらない点も特徴なのだそう。
値オブジェクトについて分かりやすくまとめている方がいたので、合わせて読んでおきたいです。
DDD基礎解説：Entity、ValueObjectってなんなんだ
参考文献
現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
第1章：小さくまとめてわかりやすくする（p13〜p46）