Q&A形式で学ぶ「システム設計」（第3〜4章）

Posted at 2025-09-28

はじめに

最近、「現場で役立つシステム設計の原則」を読んでいるので、本書の中で自分が疑問に感じたポイントをQ&A形式で振り返ってみたいと思います。

この記事では、各セクションの簡単な説明の後に、[Q]で疑問に感じたこと、[A]で調べてわかったこと、そして[NOTE]で覚えておきたいことをまとめています。

なお、サンプルコードにJavaを使用していますが、言語を問わず広く有効な設計手法なので、他言語でも応用できる内容になっています。

第1～2章については、すでに別の記事にまとめているので、こちらもぜひご覧ください！

それでは、第3〜4章を振り返りながら、一緒に「システム設計」について学んでいきましょう！

三層 + ドメインモデルの構造では、業務ロジックを記述するのはドメインモデルだけです。

業務的な判断／加工／計算のロジックは、すべて、ドメインモデルを構成するドメインオブジェクトに任せます。

ドメインモデルに業務ロジックを集約して整理できれば、プレゼンテーション層／アプリケーション層／データソース層の記述は簡潔でわかりやすくなります。

業務アプリケーションのコードが複雑になる理由は、業務ロジックの複雑さです。

業務ロジックの複雑さをドメインモデルとして分離し整理することで、三層のコードはシンプルになり、構造も単純になります。

[NOTE]
アプリケーションの各クラスの責務は以下を参考に分割するとよい。

名前	役割
プレゼンテーション層	UIなど外部との入出力を受け持つ
アプリケーション層	業務機能のマクロな手順の記述
データソース層	データベースとの入出力を受け持つ
ドメインモデル	業務データと関連する業務ロジックを表現したドメインオジェクトの集合

ドメインモデルの設計とは、業務を理解するための分析と、ソフトウェアとして実現するための設計が、一体になった活動です。

ドメインモデルは業務知識のかたまりです。

ドメインモデルを構成するドメインオブジェクトを設計する人間が、業務の関心事を理解すればするほど、業務ロジックを体系的にわかりやすく整理できます。

業務アプリケーションの複雑さは、業務ロジックの複雑さをそのまま反映しています。

ドメインオブジェクトは、業務の関心事に直接的に対応します。

クラス名やメソッド名は業務の用語そのものです。

ドメインオブジェクトを使って、業務ロジックをうまく整理できていれば、どこに何が書いてあるかがわかりやすく、業務要件に修正や追加があっても、ソフトウェアの変更は楽で安全になります。

[NOTE]
プログラムを開発するときに機能を中心に考え、機能を分解しながらプログラム部品を作っていくと、一つひとつの部品は、機能の分解構造に依存します。

つまり、上位の機能部品と、それを分解して定義した下位の機能部品はかんたんに切り離せなくなります。

ドメインモデルを構成する個々のドメインオブジェクトの設計では、こういう機能の分解構造や時間的な依存関係を持ち込まないようにします。

どうやって機能を実現するかに注目するのではなく、ある特定の業務のデータとそのデータを使った判断／加工／計算の業務ロジックだけを切り出した独立したオブジェクトを作ります。

たとえば、消費税クラスは消費税率と税額計算や端数の丸めのロジックをまとめた独立した部品として開発します。

消費税クラスのオブジェクトが、どの業務機能のどこで使われるかがはっきりしなくても、設計し開発が可能です。

今回は、「現場で役立つシステム設計の原則」の第3〜4章を題材に、自分が疑問に感じたポイントを紹介しました。

ドメインモデルの視点を取り入れることで、業務ロジックを整理しやすくなり、コードの見通しもぐっと良くなるはずです。

今後も読み進めながら、気づきがあればこうした形でまとめていきたいと思います！