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

はじめに

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

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

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

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

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

アプリケーション層のクラスの役割

三層 + ドメインモデルの設計では、アプリケーション層は処理の流れの進行役であり、調整役です。

• プレゼンテーション層からの依頼を受ける
• 適切なドメインオブジェクトに判断／加工／計算を依頼する
• プレゼンテーション層に結果（ドメインオブジェクト）を返す
• データソース層に記録や通知の入出力を指示する

三層 + ドメインモデルのアプリケーション層のクラスは、プレゼンテーション層に対して、業務サービスを提供します。

業務サービスを提供するという意味で、アプリケーション層のクラスをアプリケーションサービスクラス、または単にサービスクラスと呼びます。

三層 + ドメインモデルは、概念的にはシンプルです。

サービスクラスは、プレゼンテーション層が要求するドメインオブジェクトを返したり登録するだけです。

サービスクラスに詳細なロジックを記述しません。

[NOTE]
アプリケーション層の役割を図にすると以下のようになります。

データの整理に失敗しているデータベース

プログラムがわかりにくく複雑になっている原因が、データベース設計やデータ内容の問題であることがよくあります。

• 用途がわかりにくいカラム
• 巨大なテーブル
• テーブル間の関係のわかりにくさ

こういう問題の多いデータベースを扱うプログラムは、データの妥当性を判定したり、例外的なデータを扱うための前処理や後処理などに if 文が増え、プログラムが複雑になりがちです。

拙い設計のデータベースのテーブルを参照したり、データを適切に記録するには、テーブル定義やデータ内容に現れない暗黙の知識が大量に必要になります。

データベースを操作するときに、なぜそうするかを理解できないまま、既存のプログラムに埋め込まれたおまじないのようなコードを理由もわからず使い続けるはめになります。

[NOTE]
データベースの設計で大切なのは、難しい理論や高度な分析能力ではありません。

データベースに用意されている基本的なしくみをきちんと使うことです。

拙いデータベース設計になる原因は、そういう基本が守られていないからです。

次のような基本を実践するだけで、データベースは見違えるようにわかりやすくなります。

• 名前を省略しない
• 適切なデータ型を使う
• 制約をきちんと使う
  • NOT NULL制約
    • 起きた事実を記録すべきなのに、不明であるとしてはいけません。
  • 一意性制約
    • 記録したデータをあとから参照するときに、データの重複やあいまいさに苦しまなくてよくなります。
  • 外部キー制約
    • 事実として正しく記録された複数のテーブルの関係を明確にします。

おわりに

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

サービスクラスをシンプルに保ち、データベース設計の基本を守って、実務での複雑さを減らしていきましょう！

なお、続きとなる第7～8章の記事も公開しているので、ぜひあわせてご覧ください！