Introduction

In a distributed software architecture we don’t typically end up with  whole entities. e.g. a customer entity.  What we typically see (if we have well defined service boundaries, adhering to the distributed system design fallacies and SOA tenants) is fragments of data, owned by different service boundaries.

We want to provide our end users with a meaningful way of interacting with our system, therefore we need to compose data together.

UI Composition

There are several options we can pick from when thinking about how we should compose data back together.  We can choose to compose data:

1. In our views.
2. In our models.
3. In our data layer.

This post looks specifically at server side model composition. Subsequent posts on the topic of UI composition may look at view composition and data layer composition.

Server Side Model Composition

The easiest approach is to implement the API gateway pattern. However this introduces hard coded orchestration and therefore coupling. If we introduce coupling here, specifically efferent coupling, we find our service boundaries cannot operate totally autonomously and we introduce unwanted inefficiencies into our development process.

A different approach, that draws from the pipes and filters pattern (from the enterprise architectural patterns book),  in my opinion offers a solution that takes into account the shortcomings above.

With this in mind, a basic implementation would:

1. Use a custom HTTP request handler to match a request to interceptors.
2. Interceptors all populate a view model with the data they own.
3. Once all interceptors have complete, return the fully composed view model.

This diagram shows at a high level what this might look like:

 

In the next blog post in this series we’ll look at how we might implement something like this in .Net.

Implementing server side model composition in distributed systems.