現場で役立つシステム設計の原則

日本最大級となる 60 万件以上の求人情報サイト「イーキャリア JobSearch」の主任設計者ほか数多くの経験を持つ著者が「現場でこんなことに困っていた」「解決策としてこうやった」「その結果こうなった」というリアルな経験と「なぜ、そうするのか」をふまえて解説!

修正のたびにあちこちを書き直す羽目になり、ちょっとした変更が思いもよらない場所まで影響して大幅なやり直しになる。『現場で役立つシステム設計の原則』 (増田亨 著、技術評論社、2017 年 7 月刊、A5 判) は、こうした変更の大変さの原因をソフトウェアの設計の問題として捉え、オブジェクト指向設計で変更を楽で安全にするやり方と考え方を、具体的なコードを示しながら解説する実践書です。副題は「変更を楽で安全にするオブジェクト指向の実践技法」、登録されている英題は Principles of the Systems Architecture で、版元がすすめる読者はシステム設計のポイントを知りたいエンジニアです。著者の増田亨氏は、刊行時点の版元プロフィールでは有限会社システム設計 代表、ギルドワークス株式会社 取締役、業務アプリケーションのアーキテクトで、日本最大級の求人情報サイトの主任設計者として紹介されています。

全 10 章の構成、小さなクラスからドメインモデル、Web API まで

構成は第 1 章から第 10 章までの全 10 章です。第 1 章「小さくまとめてわかりやすくする」では、わかりやすい名前、短いメソッドと小さなクラス、基本データ型の落とし穴、値を扱うための専用のクラスを不変にすること、コレクション型を扱うロジックを専用クラスに閉じ込めることを扱い、第 2 章「場合分けのロジックを整理する」では else 句をなくす、区分ごとのロジックを別クラスに分ける、Java の列挙型を使う、状態の遷移ルールを記述するといった条件分岐の整理法が並びます。第 3 章はデータとロジックを別のクラスに分けることがわかりにくさを生むという問題提起から、三層＋ドメインモデルで関心事を分離する方針へ進み、第 4 章「ドメインモデルの考え方で設計する」がドメインオブジェクトの見つけ方や業務の言葉をコードと一致させる進め方を、第 5 章がサービスクラスとリポジトリによるアプリケーション機能の組み立てを扱います。後半は第 6 章がデータベース設計 (NOT NULL 制約 / 一意性制約 / 外部キー制約と、コトに注目するデータベース設計)、第 7 章が画面とドメインオブジェクトの連動 (タスクベースのインターフェース)、第 8 章がアプリケーション間の連携 (HTTP 通信の約束事、Web API のバージョン管理、非同期メッセージング) で、第 9 章がオブジェクト指向の開発プロセス、第 10 章がオブジェクト指向設計の学び方と教え方を扱い、参考書籍として『実装パターン』『オブジェクト指向入門』『ドメイン駆動設計』を紹介して閉じます。

変更が大変になる原因と、値オブジェクト / 区分オブジェクトという処方

業務アプリケーションの変更が大変になる典型は、データだけを持つクラスと手続きだけを持つクラスに分かれ、同じ業務ルールがあちこちの手続きに重複して書かれる構造です。金額や数量を int や String のような基本データ型のまま引き回すと、値の範囲や単位の制約はコードの各所に散らばった if 文で守ることになり、区分や種別が増えるたびに条件分岐が増殖します。本書の処方は、値の範囲を制限した専用の型を作って 不変 に扱う値オブジェクト、区分ごとのロジックを別クラスに分けて同じ型として扱う区分オブジェクト、配列やコレクションを扱うロジックを専用クラスに閉じ込めるコレクションオブジェクトという、小さな部品にロジックを寄せる設計です。こうして利用者の関心事とプログラミング単位を一致させ、業務に使っている用語をクラス名にする考え方は、ドメイン駆動設計 が中心に置くドメインモデルの実装に直結しており、版元プロフィールでも著者は日々ドメイン駆動設計を実践していると紹介されています。オブジェクト指向の言語を使っていながら設計のやり方が手続き型のままというケースを何度も見てきたので、発想を転換する手がかりにしてほしい、というのが「はじめに」で著者自身が述べる本書の狙いです。

Java と Spring を前提にした読み方と、2017 年時点の位置づけ

「はじめに」によれば、サンプルコードのプログラミング言語は Java、アプリケーションフレームワークは Spring Framework と Spring Boot です。著者自身が、ほかの言語やフレームワークを使う読者には理解しにくい箇所があるかもしれないが、設計の考え方とやり方には言語やフレームワークの違いを超えて活用できる部分があるはずだと書いており、Java 以外の読者は文法の細部よりも設計判断の理由を読む姿勢が合います。読み進めるうえで役立つのは、クラスとメソッドを書ける程度の Java の基礎と、業務アプリケーションを一度は保守した経験で、オブジェクト指向の文法そのものを初めて学ぶ段階の人には、説明が実務の困りごとから始まる分だけ抽象的に感じられるかもしれません。刊行は 2017 年 7 月で、目次には Spring の操作手順を扱う章はなく、タスクベースに分ける設計が今後の主流という見通しも 2017 年時点の視点として読む必要があります。特定フレームワークの操作手順やアルゴリズム、性能チューニングを求める人には向かず、逆にフレームワークが変わっても残る設計の判断基準を欲しい人にこそ価値があります。

業務システムの変更に苦しむ開発者が買うと元が取れる理由

元が取れるのは、業務アプリケーションの機能追加や仕様変更のたびに影響範囲が読めずに苦しんでいる開発者と、コードレビューでロジックの置き場所の判断を言葉で説明したいリーダーです。読み通すと、値オブジェクト / 区分オブジェクト / コレクションオブジェクトという小さな部品でロジックの置き場所を決め、三層とドメインモデルの役割分担でサービスクラスの肥大化を防ぎ、テーブル設計や Web API の設計までを同じ関心事の分離という考え方で見直せるようになります。第 9 章「オブジェクト指向の開発プロセス」が扱う、ソースコードを第一級のドキュメントとして活用する進め方や、見積もりと契約、進捗の判断、品質保証、要員と体制といった論点は、開発チームのマネジメントに関わる人にも直接役立ちます。類書との位置づけでは、設計原則を抽象的に論じる本と違い、業務システムの現場の困りごとから出発して具体的なコードで説明する点が本書を選ぶ理由で、他の設計書との組み合わせ方は 設計 / アーキテクチャ本の選び方 が参考になります。動くコードは書けるのに変更が怖い、という段階にいる人にとって、本書は次の一歩を具体的なコードで示してくれる一冊です。