最近、SoundCloudのドメインゲートウェイの実装に向けたサービスアーキテクチャの進化について説明する2つの記事が公開された。付加価値サービスはその過程にある。著者は、これらのドメイン駆動設計ベースのパターンがどのように重複を減らし、ビジネスと認可のロジックを均質化する役に立ったかを説明している。
付加価値サービスは、呼び出し元にアグリゲートエンティティを提供することを前提とするサービスである。ドメインゲートウェイを使うと、異なるドメイン間で同じエンティティを管理できる。
著者によると、SoundCloudの最初のサービスアーキテクチャには2つのサービスレイヤがあった。エッジサービスは、基盤サービスからすべてのデータを取得する。各エッジサービスは、すべての呼び出しを調整し、認可の役割も担った。最終的にこのパターンでは、異なるサービスがわずかに異なる方法で同じデータを使用するように進化したときに、コードとロジックの重複につながった。
著者は、同社のサービスアーキテクチャの2番目の進化のステップは、付加価値サービス（VAS）パターンを実装する3番目の中間層を追加することで構成されていたと書いている。そのような付加価値サービスへの切り替えは、責任をよりよく分割することを可能にした。エッジレイヤはAPIゲートウェイ機能を提供し、特定のクライアントニーズを満たす。一方で、VASレイヤは基盤サービスからのデータを消費し、それを処理してアグリゲートエンティティにする。次に、エッジレイヤサービスはこれらのアグリゲートを消費する。
出典: https://developers.soundcloud.com/blog/service-architecture-2
VASなどのパターンには欠点がいくつかある。著者はこれを、より広範なサービスランドスケープとネットワーク遅延の増加と特定している。その理由は、新しい中間サービスによって導入された余分なホップによるものだ。彼らは代わりに共有ライブラリを使用することを検討している。そして、彼らが想定するユースケースでは、VASレイヤが適切であると結論付けた。
付加価値サービスでの部分的な応答のサポートにより、各クライアントのニーズに返されるデータの量を調整できる。部分的な応答によって、ネットワーク呼び出しの数を減らせるかもしれないが、著者は、SoundCloudが注力するのはエッジレイヤでの複雑さを管理することであると述べている。
著者は、付加価値サービスが最終的にはエンティティデータを変更する機能を含む形に成長したと付け加えている。別々のインターフェイスにすることで書き込み操作を読み取り操作から分離した。これは、よく知られているコマンドクエリ責任分離（CQRS）パターンのコアを構成する「コマンド」と「クエリ」の概念を使用したものだ。
SoundCloudのVASのスコープが拡大するにつれて、異なる目的と認可要件を持つ異なるドメインで、同じエンティティが使用されていることが注目されるようになったと著者は指摘している。ドメインゲートウェイパターンは、同じサービスで考えられるすべてのバリエーションの実装を回避するために選択されたソリューションであった。著者は、このゲートウェイサービスを、特定のビジネスドメインに関連付けられたVAS実装として説明している。
著者によると、ゲートウェイサービスの導入によって起こる重複は、「異なるドメインのアクセスパターンが大きく異なり、機能セットに全く関連がない場合、またはチーム間のコミュニケーションとコラボレーションが難しい場合」に役に立つ。
この2つのSoundCloudブログ記事は、InfoQですでに取り上げたBackends For Frontendsパターンに関する記事に続くものである。アグリゲートはドメイン駆動設計パターンであり、単一のユニットとして扱うことができるドメインオブジェクトのグループを表す。付加価値サービスとドメインゲートウェイのパターンは、業界で使用されているドメイン指向のアーキテクチャの形式である。