ViewModel Composition header image

ViewModel Composition

Designing a UI when the back-end system consists of dozens (or more) of microservices is a challenge. We have separation and autonomy on the back end, but on the front-end this all needs to come back together. ViewModel Composition stops it from turning into a mess of spaghetti code, and prevents simple actions from causing an inefficient torrent of web requests.

When building systems based on SOA principles service boundaries are a key aspect, if not THE key aspect. If we get service boundaries wrong the end result has the risk to be, in the best case, a distributed monolith, and in the worst one, a complete failure.

Service boundaries identification is a challenge on its own, it requires a lot of business domain knowledge and a lot of confidence with high level design techniques. Other than that there are technical challenges that might drive the solution design in the wrong direction due to the lack of technical solutions to problems foreseen while defining service boundaries.

The transition from the user mental model, what the domain expert describes, to the service boundaries architectural model in the SOA space raises many different concerns. If domain entities, as described by domain experts, are split among several different services:

  • how can we then display to users what they need to visualize?
  • when systems need to make decisions how can they “query” data, required to make that decision, stored in many different services?

This type of questions lead systems to be designed using rich events, and not thin ones, in order to share data between services and at the same to share data with cache-like things, such as Elastic Search, to satisfy UI query/visualization needs.

This is the beginning of a road that can only lead to a distributed monolith, where data ownership is a lost concept and every change impacts and breaks the whole system. In such a scenario it’s very easy to blame SOA and the tool set.

ViewModel Composition techniques are designed to address all these concerns. ViewModel Composition brings the separation of concerns, desinged at the back-end, to the front-end.

Articles in this category:

What is Services ViewModel Composition, again?


Building distributed systems requires facing an interesting challenge: there is a dichotomy between the way behaviors and data are decomposed at the backend and the way users expect to consume them from the frontend. Services ViewModel Composition techniques are designed to help us overcoming this dichotomy.

Continue reading...

The Services ViewModel Composition maze


ViewModel Composition can be scary, at a first look. The real world, we deal with every day, is complex as the information we manage are complex. Do we need to manually craft dedicated solutions or can we extract reusable patterns? There is always an exit to the maze.

Continue reading...

Into the darkness of ViewModels Lists Composition


ViewModels Lists composition has an interesting challenge: must be designed in such a way that it doesn't flood servers with tons of requests. Number of requests cannot exceed the number of services involved in the composition process, no matter how many items are composed. There is a light at the end of the tunnel (cit.)

Continue reading...

ViewModel Composition: show me the code!


Time was spent discussing ViewModel Composition concepts and their design. It's time for some code. Let's see Single Item Composition in action: how does the code look like?

Continue reading...

There is no such thing as cross-service ViewModel Composition


At a first look it might sound reasonable to use ViewModel Composition to allow services to talk to each other. Why not allowing services to share complex data structure composed at runtime? Let me put it simple: you don't want a distributed monolith!

Continue reading...

The ViewModels Lists Composition Dance


Composing a list in an efficient way is complex. Multiple components need to interact with each other to produce the final result. It's not that different from a chorus, where each dancer performs the studied choreography so that the end result is an amazing ballet.

Continue reading...

Read models: a knot to untie


Read models can be a tempting solution when it comes to presenting data in a distributed system. Before going down this route it's important to disclose the very nature of the choice we're going to make. It's a knot to untie.

Continue reading...

Turn on the motors


It's time to discover all the nitty gritty details of the Composition Gateway. It's going to be a roller-coaster ride from ASP.Net Core Routing to the composition engine and back. Fasten your seat belt and enjoy the ride!

Continue reading...

Slice it!


We desperately strive to achieve autonomy at the back-end, but not so much when it comes to front-ends. Using ViewModel Composition techniques we can achieve autonomy at the front-end as well. There should not be any such thing as orchestration though.

Continue reading...

The fine art of dismantling


What happens when there is the need to write data in a distributed system? What if this data needs to go to different services? How do services participate in this process like they do for the Composition part? This is when ViewModel Decomposition comes into play. Let's have a look at what it is and especially when it's really needed.

Continue reading...