ほとんどの社内REST APIは、単一の統合ポイント用に構築された、特注のAPIです。この記事では、非公開APIの制約と柔軟性、そして複数のチームにわたる大規模なRESTful統合から得られた教訓について説明します。

RESTアプローチの主要な要素を3つのステップに分解したモデル（Leonard Richardsonによって開発）。これらのステップでは、リソース、HTTP動詞、そしてハイパーメディアコントロールが導入されます。

優れた技術設計の決定は、コンテキストに大きく依存します。共通の目標に向かって定期的に協力するチームは、定期的にコミュニケーションを取り、変更を迅速に交渉することができます。これらのチームは、連携という強い力を発揮し、その強い力を活用した技術と設計の決定を下すことができます。大規模な組織になると、独立して作業し、共同作業の頻度が少ないチームや部門間には、ますます弱い力が存在します。これらの強弱の違いを認識することで、各レベルでより良い意思決定を行い、より良いガイダンスを提供することができ、より権限を与えられたチームがより速く行動できるようになります。

商用統合ツールは20年ほど前から存在しますが、いつどのように使用するかを記述した包括的なアーキテクチャ原則はほとんどありませんでした。この記事では、「購入」の意思決定メカニズムによって、そのようなツールの価値提案が誇張され、汎用言語よりも特定の統合ツールを使用することが義務付けられることが多くなったと主張します。このようなツールは、統合を主にシステムの接続と見なす世界ではうまく機能しますが、デジタル組織は統合を、デジタル機能の前にクリーンなインターフェースを配置すること、つまりシステムよりも機能を重視することであると再定義していると主張します。最後に、統合の現代的な見解の背後にある主要な原則をいくつか挙げ、それらは汎用言語で管理するのが最適であり、商用統合ツールの主要な価値提案を、戦術的な実装上の懸念の簡素化に方向転換させると主張します。

私の同僚であるJim Webberは、エンタープライズにおける統合に、軽量でビジネス指向のアプローチを採用することで、かなりの評判を築いてきました。彼はまた、非常に力強く、面白い講演者としても知られています。そのため、QCon 2008の基調講演で彼とステージを共有することになった時は、興奮する反面、緊張していました。彼は、真面目な話題を織り交ぜた、素晴らしく面白いプレゼンテーションをまとめました。それから私たちはただ飛び込んで、それを実行しました - プレゼンテーション前のビールが helpedれたのかもしれません。私たちは、エンタープライズ統合の歴史、強力だと思っているが実際にはただ太っているだけのシステムの成長、アジャイル思考の役割、Webの影響（Webがなぜ発明されたのかについてのJim独自の理論を含む）、そしてこれがどのようにゲリラSOAにつながるのかについて話します。

この記事では、サービスプロバイダーとコンシューマのコミュニティを進化させる上での課題について説明します。サービスプロバイダーが契約の一部、特にドキュメントスキーマを変更した場合に発生する結合の問題について説明し、スキーマ拡張ポイントの追加と受信メッセージの「必要最小限の」検証の実行という、よく理解されている2つの戦略を特定して、このような問題を軽減します。どちらの戦略も、プロバイダーの契約変更からコンシューマを保護するのに役立ちますが、どちらも、プロバイダーがどのように使用されているか、そして進化するにつれて維持しなければならない義務について、プロバイダーに洞察を与えるものではありません。これらの軽減戦略の1つである「必要最小限の」検証戦略のアサーションベースの言語に基づいて、この記事では、「コンシューマ主導型契約」パターンについて説明します。このパターンは、プロバイダーにコンシューマの義務についての洞察を提供し、コンシューマが要求する主要なビジネス機能の提供を中心にサービスの進化を集中させます。

近年、スキーマレスデータの利点についての話が増えています。スキーマレスであることは、NoSQLデータベースへの関心の主な理由の1つです。しかし、スキーマレス性には、データベースとメモリ内データ構造の両方に関して、多くの微妙な点があります。これらの微妙な点は、スキーマレスの意味と、スキーマレスアプローチを使用することの利点と欠点の両方に存在します。

（統合データベースとは対照的に）単一のアプリケーションによって制御およびアクセスされるデータベースをアプリケーションデータベースと呼びます。単一のアプリケーションのみがデータベースにアクセスするため、データベースはその1つのアプリケーションのニーズを簡単に満たせるように具体的に定義できます。これにより、統合データベースよりも理解しやすく、多くの場合複雑でない、より具体的なスキーマが実現します。

境界づけられたコンテキストは、ドメイン駆動設計の中心的なパターンです。これは、大規模なモデルとチームの扱い方に関する、DDDの戦略的設計セクションの焦点です。DDDは、大規模なモデルを異なる境界づけられたコンテキストに分割し、それらの相互関係を明確にすることで、大規模なモデルを扱います。

データベースとアプリケーションの関係について話すとき、データベースの2つのスタイル、アプリケーションデータベースと統合データベースを区別すると便利だと感じています。2つの違いは、データベースが単一のアプリケーション境界内で制御およびカプセル化されているかどうかです。

今世紀初頭、私は著書エンタープライズアプリケーションアーキテクチャパターンに取り組みました。この本を書く際に問題となったことの1つは、タイトルの付け方、つまり、私が書いている種類のソフトウェアシステムを何と呼ぶかでした。私は、自分のソフトウェア開発の経験が常に1つの特定の形式のソフトウェア、つまり医療記録、外国為替取引、給与計算、リース会計などに焦点を当ててきたことを常に意識していました。これらは、プリンター、ゲーム、飛行制御ソフトウェア、または電話交換機に組み込まれているソフトウェアとは大きく異なります。これらの種類のシステムを記述するための名前が必要で、「エンタープライズアプリケーション」という用語に落ち着きました。

最近、エンタープライズアプリケーションアーキテクチャパターンについて、エンタープライズアーキテクチャに関する記述がないため、Amazonでいくつかの悪いレビューを受けました。もちろん、それには正当な理由があります。この本はエンタープライズ*アプリケーション*アーキテクチャ、つまりエンタープライズアプリケーションの設計方法について書かれています。エンタープライズアーキテクチャは別のトピックであり、企業内の複数のアプリケーションをどのように首尾一貫した全体に編成するかということです。

SOAはアジャイルアプローチで実行できますか？

SOA推進派が喧伝する新しいサービスの世界の特徴の1つは、レジストリの概念でした。多くの場合、これは、システムがレジストリで有用なサービスを自動的に検索し、それらのサービスをすべて自動的にバインドして消費できるようにする自動化システムの観点から説明されました。

コンピュータは時折賢そうに見えるかもしれませんが、私は特にその考えに賛同していません。自動化されたサービス検索にはまれに例外的なケースがあるかもしれませんが、20回中22回は人間のプログラマーが検索を行うことになると思います。

統合データベースとは、複数のアプリケーションのデータストアとして機能し、それらのアプリケーション全体でデータを統合するデータベースです（アプリケーションデータベースとは対照的です）。

大企業を詳しく調べると、通常、全社的な概念モデリングに焦点を当てたグループが見つかります。ほとんどの場合、これはデータ管理グループであり、場合によっては全社的なサービスの定義に関与している場合があります。彼らは単一のアプリケーションの取り組みに焦点を当てるのではなく、複数のアプリケーションの統合に集中するため、全社的です。

サービス指向アーキテクチャ向けのサービスを構築する人にとって重要な考え方です。サービスを構築する際には、クライアントがテストに使用できるサービススタブも構築してください。このようなスタブは、固定された一連のリクエストに対して既定の応答を提供し、エラー状態をシミュレートし、クライアントのマシンで実行可能である必要があります。スタブが実際のシステムの動作を適切に模倣していることを確認する必要があります。クライアントにスタブを提供することで、クライアントはサービスをはるかに簡単に使用できるようになります。もちろん、これはサービスが使用される可能性が高くなることを意味します。

企業のコンピューティングニーズが、効果的なコラボレーションを可能にするために互いにサービスを提供する多くの小さなアプリケーションに分割されている、SOAの幸福な世界を想像してみましょう。ある晴れた朝、コンシューマーサービスはサプライヤーサービスからいくつかの情報を必要としています。問題は、サプライヤーサービスはこの情報を取得するために必要なデータと処理ロジックを備えているにもかかわらず、まだその情報をサービスインターフェースを介して公開していないことです。サプライヤーは潜在的なサービスを持っていますが、実際にはまだ存在していません。

Thoughtworksが軽率に私をクライアントの前に出すときはいつでも、「SOA（サービス指向アーキテクチャ）についてどう思いますか？」という質問を必ずされます。SOAは人によって非常に多くの異なる意味を持つため、答えるのが非常に難しい質問です。

Webサービスを使用する利点の1つは、システムのさまざまな部分を分離できることです。人々は、ある程度の分離を持って別々のコードベースで作業できます。ある程度の分離は得られますが、サービスは依然としてインターフェースを介して相互に通信する必要があるため、結合を完全に排除することはできません。悲しいことに、多くのチームはこの結合を本来あるべきよりもはるかに悪化させています。