Domain editor

Domain-driven design with value-added services and domain gateways at SoundCloud

Two articles were recently published to describe the evolution of SoundCloud’s service architecture towards implementation of domain gateways, with a stop at Value-added services on my way. The authors describe how these domain-driven design-based models have helped reduce duplication and standardize business and authorization logic.

A value-added service is a service responsible for providing aggregated entities to its callers. Domain gateways allow you to manage the same entity on different domains.

According to the authors, SoundCloud’s first service architecture had two service layers: edge services retrieved all data from backbone services. Each edge service orchestrated all of its calls and was also responsible for authorization. Ultimately, this model led to duplications of code and logic as different services evolved to use the same data in slightly different ways.

The authors write that the second evolutionary step of the enterprise service architecture was to add a third middle layer implementing the Value Added Services (VAS) model. Such a shift towards value-added services has made it possible to better distribute responsibilities. The edge layer provides API gateway capabilities and addresses specific customer needs, while the VAS layer consumes data from basic services, processing it into aggregate entities. Edge layer services then consume these aggregates.

Source: https://developers.soundcloud.com/blog/service-architecture-2

A model like VAS has some drawbacks, which the authors identified as a larger service landscape and increased network latencies due to the additional hops introduced by new intermediary services. Instead, they considered using shared libraries and concluded that a VAS layer is preferable in their case.

Support for partial responses in value-added services makes it possible to tailor the amount of data returned to the needs of each customer. Partial responses can also reduce the number of network calls, but the authors state that SoundCloud’s goal is to manage complexity at the edge layer.

The authors add that their value-added services eventually evolved to include the ability to modify entity data. Separate interfaces isolate write operations from read operations using the concepts of “command” and “request”, which form the core of the well-known model of Separation of Responsibility for Command Requests (CQRS).

As SoundCloud’s VAS expanded, it became evident that the same entities were used in different areas with different purposes and permission requirements, the authors point out. The Domain Gateway model was the solution chosen to avoid implementing all possible variations in the same service. The authors describe these gateway services as VAS implementations tied to specific business areas.

According to the authors, the duplication introduced by gateway services makes sense “in cases where different domains have very different access patterns and very disjointed feature sets, or where communication and collaboration between teams is difficult ”.

These two SoundCloud blog posts follow on from a previous post on the Backends For Frontends model, already covered on InfoQ. a the aggregate is a domain-driven design model and represents a group of domain objects that can be treated as a single unit. The value-added services and domain gateway models are domain-oriented architectural forms for use in industry.