レイヤ化

🐾 猫で例えると？

椅子の上と下、それぞれの場所からこちらをうかがう2匹。猫たちの居場所を、役割ごとに分けた「層」に見立ててみましょう。例えば上段が画面表示、下段がデータを取り出す担当、という具合です。システムでは居場所を分けるだけでなく、どの層が何を担当し、どの層へ頼むかを決めることがレイヤ化の要点です。

💻 IT現場における「レイヤ化」とは？

たとえば表示、業務ルール、データアクセスに分けると、各処理の置き場所を考えやすくなります。この論理的なレイヤーと、別サーバーなどへの物理的な配備層（tier）は区別します。3レイヤーでも一つのプロセスで動かせます。

表示色だけの変更なら保存処理を触らずに済む構造を目指します。ただし層を作っただけで影響がゼロになるわけではありません。APIの項目や意味を変更すると、呼び出し側にも変更が必要です。

⚠️ レイヤ化の仕組みとメリット

層ごとに責務と依存方向を決めることで、内部の変更を局所化しやすくなります。すぐ下の層だけを呼ぶ方式や、必要に応じて複数層を利用する方式などがあり、守る規則をプロジェクトで明示します。

シンプルな3層アーキテクチャのコード例

役割ごとにクラスを分割し、上位の層が下位の層を利用する流れを見てみましょう。

// JavaScript：架空のおやつ在庫を使う、3層の小さな例
class SnackRepository {
  getCount() { return 3; } // 説明用の固定データ
}
class SnackService {
  constructor(repository) { this.repository = repository; }
  canPrepare(requested) {
    return Number.isInteger(requested) && requested > 0 &&
      this.repository.getCount() >= requested;
  }
}
class SnackView {
  constructor(service) { this.service = service; }
  show(requested) {
    console.log(this.service.canPrepare(requested) ? "用意できます" : "用意できません");
  }
}
new SnackView(new SnackService(new SnackRepository())).show(2);

この例では在庫取得、用意できるかの判定、表示を分けています。保存先を変えるならRepository、表示文だけならViewが中心です。ただし実際の在庫確保では同時更新への対策が必要で、この確認だけで在庫が予約されるわけではありません。

🛠️ レイヤ化を賢く使うためのポイント

現場でレイヤ化アーキテクチャを導入・運用する際には、以下の点に気をつけましょう。

• 層をまたいだ呼び出し（依存関係のルール）を守る： プレゼンテーション層のコードから直接データベースにアクセスするなど、層を飛び越えた処理（スパゲッティコード）を行うと、レイヤ化の恩恵である「変更への強さ」が失われてしまいます。
• 過剰なレイヤ化は避ける： ごく簡単なアプリでレイヤを細かく分けすぎると、ただ単にデータを右から左へ受け渡すだけ（バケツリレー）の無駄なコードが増え、開発スピードが落ちる原因になります。規模に合わせた設計が重要です。
• テストがしやすくなる： レイヤごとに処理が独立しているため、ダミーのデータ（モック）を使って「ビジネスロジック層だけ」を切り離して自動テストすることが容易になります。

椅子の上下を使い分ける猫たちのように、レイヤーは役割を分けて考える助けになります。画面、業務処理、データの保存などを分けたら、どの層がどの層を呼び出すかも決めると、変更時に調べる範囲を絞りやすくなります。