Before we do the breakup and high-level design of microservices with respect to the teams, let's develop and understand the conventions that we will keep in our design, as sort of agreed between our team of architects for building this new system.

All the respective boxes below in context diagrams showing the systematic context for each team are the high-level microservice designs based directly on the bounded contexts determined by the respective responsible teams. 

We have decided that all of the user interface components for all the contexts will be treated as a separate microservice. Meaning, they will be packaged and deployed separately as an independent process other than its respective system interfaces microservice. Both are isolated but sort of dependent, but they can be available on the same machine or a VM.

The user interface microservice basically does not expose any service, and is, primarily, a services consumer. UI components usually consume the services from its own bounded contexts. As per convention, we will try that all external (outside the bounded context) service interfaces are linked to our system interfaces, and not to user interface, wherever possible.

Most of the user interface services can be made as SPA. Our user interface app for the platform administration team is not necessarily an SPA, but it's a special app interface which basically combines all other teams' interfaces under one umbrella. So we will design our user interfaces, technically, in a way that they are embeddable UIs without losing the user experience (UX). Rather, they should somehow enrich the main portal, which is represented as a software under the platform admin team.

All the service-callable interfaces that represent APIs or some functionality are exposed by the system interfaces microservice. So we will basically have a number of system interfaces microservices from various team contexts talking to each other.

The big boxes on the right of each context which basically represent an external system, which is being utilized as a separate interface integrated into our services context. In a way, it depicts our business case as well as the technical scenario in an easy and simple format. It does not exactly show the services that are being exposed by the respective systems, but in real life, it will show all the essential connection points.

Similarly, we have only shown very few basic and only high-level services exposed by our microservice's system interfaces for each team's context. This is only for demonstration purpose.