生産性爆上げ仕事術

分散システム開発の連携ミスを防ぐ 契約ドリブン開発（CDD）の実践フレームワーク

Tags: 契約ドリブン開発, CDD, マイクロサービス, API開発, 分散システム, テスト戦略, フレームワーク

近年、システム開発において分散システムやマイクロサービスアーキテクチャの採用が増えています。これにより、開発チームはそれぞれのサービスに集中できるようになり、スケーラビリティや技術選択の自由度が高まるメリットがあります。しかし、同時にサービス間の連携が複雑化し、API仕様の認識齟齬による連携ミスの発生リスクも増大しています。

こうした課題に対して有効な手段の一つが、「契約ドリブン開発（Contract-Driven Development, CDD）」です。CDDは、サービス提供者（プロバイダー）と利用者（コンシューマー）の間でAPIなどの「契約」を明確に定義し、その契約を基準に開発とテストを進めるフレームワークです。本稿では、このCDDフレームワークの概念とその実践方法について、具体的なステップやメリット、導入時の注意点を含めて解説します。

契約ドリブン開発（CDD）とは

契約ドリブン開発（CDD）は、サービス間のインターフェース（APIなど）仕様を「契約」として定義し、その契約を開発の中心に据える開発手法です。この契約は、多くの場合、OpenAPI Specification（旧Swagger Specification）やgRPCのようなインターフェース定義言語（IDL）を用いて記述されます。

CDDでは、サービス提供者と利用者がまずこの契約について合意します。その後、合意された契約に基づき、双方が並行して開発を進めます。重要なのは、この契約がテストの基盤となる点です。コンシューマー側は契約に基づいてプロバイダーのモックを生成し、それに対してテストを行います（コンシューマーサイド契約テスト）。プロバイダー側は、コンシューマーが必要とする契約を満たしているかを検証するテストを行います（プロバイダーサイド検証）。

これにより、以下のようなメリットが得られます。

契約ドリブン開発の具体的な実践ステップ

CDDを実践するための一般的なステップは以下の通りです。

  1. 契約の定義と合意形成:

    • サービス提供者と利用者が協力し、サービスのインターフェース（APIのエンドポイント、リクエスト/レスポンスの形式、エラーコードなど）を詳細に定義します。
    • OpenAPI Specification、Protocol Buffers (gRPC用)、GraphQL SchemaなどのIDLや仕様書形式を用いて記述します。
    • 定義した契約内容について、関係者間でレビューを行い、全員が合意に至るまで調整します。この契約定義は、開発の「真実の情報源（Source of Truth）」となります。

  2. 契約からのモック生成（コンシューマー側）:

    • 合意された契約定義ファイルから、コンシューマーが利用するサービスのモック（スタブ）を自動生成または手動で作成します。
    • WireMockやMockoonのようなツール、あるいはOpenAPI Generatorのようなコード生成ツールが利用できます。
    • コンシューマー側チームは、このモックに対して自身の開発を進め、単体テストや結合テストを行います。これにより、プロバイダー側の開発状況に依存せず、早期に開発を進めることができます。

  3. コンシューマーサイド契約テストの作成（コンシューマー側）:

    • コンシューマーは、自身がプロバイダーのAPIをどのように利用するか、というユースケースに基づいたテストを作成します。これが「コンシューマーサイド契約テスト」です。
    • このテストでは、コンシューマーがプロバイダーのモックに対して特定のリクエストを送信し、期待するレスポンスが得られるか、あるいは特定のエラーが返されるかなどを検証します。
    • Pactのようなコンシューマーサイド契約テスト専用のフレームワークを利用すると、テストで生成された「契約内容」（コンシューマーが期待するプロバイダーの振る舞い）をファイルとして出力できます。

    ```java // 例: Pactを使ったコンシューマーサイド契約テストのイメージ (Java + JUnit 5) import au.com.dius.pact.consumer.MockServer; import au.com.dius.pact.consumer.dsl.PactDslWith courteousRequests; import au.com.dius.pact.consumer.junit5.PactConsumerTestExt; import au.com.dius.pact.consumer.junit5.PactTestFor; import au.com.dius.pact.core.model.RequestResponsePact; import au.com.dius.pact.core.model.annotations.Pact; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.extension.ExtendWith; import java.io.IOException;

    @ExtendWith(PactConsumerTestExt.class) @PactTestFor(providerName = "UserService") // テスト対象のプロバイダー名 public class UserConsumerPactTest {

    @Pact(consumer = "OrderService") // このテストを作成するコンシューマー名
public RequestResponsePact createUserExistsPact(PactDslWith courteousRequests builder) {
    // コンシューマー（OrderService）がプロバイダー（UserService）に対して期待するリクエストとレスポンスを定義
    return builder
            .given("user exists") // テストの前提条件
            .uponReceiving("a request for user details") // このリクエストを受け取ったとき
                .path("/users/123") // エンドポイントのパス
                .method("GET") // HTTPメソッド
            .willRespondWith() // このレスポンスを返すことを期待する
                .status(200) // HTTPステータスコード
                .headers("Content-Type", "application/json") // レスポンスヘッダー
                .body("{\"id\": 123, \"name\": \"Alice\"}") // レスポンスボディ
            .toPact();
}

@Test
@PactTestFor(pactMethod = "createUserExistsPact")
void testGetUser(MockServer mockServer) throws IOException {
    // モックサーバーに対してリクエストを実行し、期待通りのレスポンスが返ることを確認
    // このテストが実行されると、Pactファイル（コンシューマーが期待するプロバイダーの振る舞いを記述したもの）が生成される
    // ... (実際にHTTPクライアントを使ってmockServerにリクエストを送る処理) ...
}

    } ``` * 生成された契約ファイル（Pactファイルなど）は、プロバイダー側がアクセス可能な共有リポジトリ（例: Pact Broker）に公開します。

  4. プロバイダーサイド検証の実施（プロバイダー側）:

    • プロバイダー側は、共有リポジトリに公開されたコンシューマーからの契約ファイルを取得します。
    • 取得した契約ファイルに基づき、自身のサービス（本物のサービス）がその契約を満たしているか検証するテストを実行します。これが「プロバイダーサイド検証」です。
    • このテストでは、コンシューマーが期待するリクエストを実際にプロバイダーのサービスに送信し、期待通りのレスポンス（ステータスコード、ヘッダー、ボディなど）が返されるかを確認します。
    • Pact Brokerは、プロバイダーが検証を実行し、その結果をコンシューマーにフィードバックする仕組みも提供します。

    ```java // 例: Pactを使ったプロバイダーサイド検証のイメージ (Java + JUnit 5) import au.com.dius.pact.provider.junit5.HttpTestTarget; import au.com.dius.pact.provider.junit5.PactVerificationContext; import au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider; import au.com.dius.pact.provider.junitsupport.Provider; import au.com.dius.pact.provider.junitsupport.State; import au.com.dius.pact.provider.junitsupport.loader.PactBroker; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.TestTemplate; import org.junit.jupiter.api.extension.ExtendWith;

    @Provider("UserService") // このプロバイダーの名前 // Pact Brokerから契約を取得する場合 @PactBroker(url = "http://localhost:9292") public class UserProviderPactTest {

    @BeforeEach
void setup(PactVerificationContext context) {
    // テスト対象のプロバイダーサービスのエンドポイントを設定
    context.set target(new HttpTestTarget("localhost", 8080));
}

@TestTemplate
@ExtendWith(PactVerificationInvocationContextProvider.class)
void pactVerificationTestTemplate(PactVerificationContext context) {
    // Pact Brokerから取得した各契約に対して検証を実行
    context.verifyInteraction();
}

// コンシューマーが契約で指定した"state"（テストの前提条件）に対する準備処理を記述
@State("user exists")
public void userExists() {
    // 例: テスト用のユーザーデータをDBに投入するなどの処理
    System.out.println("Setting up state for user exists");
}

    } ```

  5. 継続的な統合とデプロイメント:

    • 上記1〜4のプロセスをCI/CDパイプラインに組み込みます。
    • コード変更が行われるたびに、契約テストとプロバイダー検証が自動的に実行されるように設定します。
    • 契約が破られている場合は、変更をデプロイしないなどの制御を行います。
    • Pact Brokerのようなツールを使うと、どのコンシューマーがプロバイダーの特定のバージョンと互換性があるか（＝契約検証に成功しているか）を可視化し、デプロイの可否を判断するのに役立ちます（Can I Deploy?機能）。

導入のメリットとデメリット

メリット

デメリット

導入を検討する際のポイント

CDDは特に以下のような状況で効果を発揮しやすいでしょう。

導入にあたっては、チーム間でCDDの哲学とメリットを共有し、共通の契約定義方法やツールの選定、CI/CDパイプラインへの組み込み計画などを事前にしっかりと話し合うことが成功の鍵となります。また、最初は一部の重要なサービス間連携からCDDを導入し、徐々に適用範囲を広げていくアプローチも有効です。

まとめ

契約ドリブン開発（CDD）は、分散システムやマイクロサービス開発におけるサービス間連携の課題に対し、契約を軸とした開発とテストで応える強力なフレームワークです。連携ミスの早期発見、並行開発の促進、信頼性の向上といったメリットは、複雑化する現代のシステム開発において、チームの生産性を劇的に向上させる可能性を秘めています。

初期導入にはコストがかかりますが、長期的に見れば手戻りの削減や開発効率の向上によって、そのコストは十分にペイされると考えられます。本稿で紹介した実践ステップや導入のポイントを参考に、ぜひ皆さんのチームでもCDDの導入を検討し、より効率的で信頼性の高いシステム開発を目指していただければ幸いです。