クリーンアーキテクチャ入門｜DBがないとテストできないコードは、設計が間違っている

1つのルールに集約される——「依存は内側へ」

覚えることは1つ。ビジネスロジックは技術的な詳細（DB・HTTP・フレームワーク）を知らない、逆は許さない。この1文が全ての図と実装の根拠になる。

クリーンアーキテクチャの提唱者Robert C. Martinが示す原則は、驚くほど短い一文に集約されます。“Source code dependencies can only point inwards.”——ソースコードの依存関係は、内側にしか向かってはいけない。

「内側」とは何か

同心円の中心にあるのがビジネスロジック（業務ルール）で、外側にDB・Web・フレームワークといった技術的な詳細が配置されます。矢印は常に外から内へ——DBの都合でビジネスロジックの書き方を変えることは許されますが、逆（ビジネスロジックの都合でDBの選択が縛られること）は起きないという一方通行の規律です。

フレームワークは「詳細」

原典はさらに踏み込みます。“does not depend on the existence of some library of feature laden software”。このアーキテクチャは、機能満載のライブラリの存在に依存しない、という主張です。フレームワークは中心ではなく周辺の「詳細」として扱われ、後から差し替え可能な部品という位置づけになります。

実際にDBなしでテストしてみる

「依存は内側へ」の効果は抽象論ではなく実測できる。ビジネスロジックをインターフェース越しに書けば、DBなしで即座にテストが走る。

クリーンアーキテクチャの原典は、テスト容易性についてこう約束しています。“can be tested without the UI, Database, Web Server, or any other external element”。ビジネスルールは、UI・DB・Webサーバー等の外部要素なしにテストできる、という主張です。実際にやってみます。

実際に動かして確かめる

以下は編集部が実際にNode.jsで実行したコードと出力です。「割引計算」というビジネスロジックを、リポジトリ（データ取得）のインターフェース越しに書き、テストではDBの代わりにメモリ上の簡易実装を差し込みます。

// ビジネスロジック: DBの存在を一切知らない。渡されたリポジトリのインターフェースだけを使う
function calculateDiscount(customerRepo, customerId) {
  const customer = customerRepo.findById(customerId);
  if (!customer) throw new Error("customer not found");
  if (customer.totalPurchase >= 100000) return 0.1; // 10万円以上で10%引き
  if (customer.totalPurchase >= 50000) return 0.05;
  return 0;
}

// テスト時: 本物のDBの代わりに、メモリ上の簡易リポジトリを差し込む
const fakeRepo = {
  findById: (id) =>
    ({ "C1": { totalPurchase: 120000 }, "C2": { totalPurchase: 30000 } })[id] ?? null,
};

console.log("C1(12万円購入)の割引率:", calculateDiscount(fakeRepo, "C1"));
console.log("C2(3万円購入)の割引率:", calculateDiscount(fakeRepo, "C2"));

C1(12万円購入)の割引率: 0.1
C2(3万円購入)の割引率: 0

何が起きたか

DBサーバーは一度も起動していません。calculateDiscountはcustomerRepoというインターフェースの形にしか依存しておらず、本番ではPrismaを使う実装、テストではメモリ上の実装を差し込めます。これが「依存は内側へ」を実装した姿です。

個人開発では「2層」から始めれば十分

原典の同心円を全部厳密にやる必要はない。ビジネスロジックと技術的詳細を分けるという1点だけを守れば、効果の大半は得られる。

クリーンアーキテクチャの解説記事はしばしば4層・5層の同心円図を示しますが、これは大規模システム向けの参考図です。個人開発で必要なのは、多くの場合2層の分離だけです。

最小構成: ビジネスロジック層と詳細層

導入の目安

全ての個人開発アプリに必要ではありません。「テストを書こうとしたらDBが要って面倒」「仕様変更のたびに動作確認が手作業になる」と感じ始めたときが導入のタイミングです。痛みが出る前に厳密にやりすぎると、小さなアプリでは過剰な抽象化がむしろ開発速度を落とします。ソフトウェア設計の記事で触れた通り、重い理論は痛みが出てから読むのが最短です。