This is where we've now taken the bottom half or the bounded context that were in the bottom half of the previous full monolithic system, auto insurance system, and we've broken those out into individual microservices. So each bounded context represents an individual microservice. represents an individual microservice. This can be done to give more autonomy to the team that's working on each bounded context, and the team that's working on each bounded context represented by a separate microservice so that they can innovate, they can work on strategy, they can work on implementation solutions separately from the other teams, independently, which gives them the ability to release software whenever they need to in order to keep up with business rule changes and other demands, and so they can keep pace with their own priorities, whereas the monolithic system, likely these components up here or these bounded contexts up here, these components up here or these bounded contexts up here don't require as progressive of actions that need to be taken for business changes, business-driven changes, and so they can work toward a common schedule where this auto insurance, the remaining part of the monolith, can be deployed together. So these are different rates of change, you could say, that is driving the reason for the separation in the kinds of architecture being used. Notice that this message bus is being used for integration, and we're showing that there is some cloud integration. Each of these microservices could be deployed to the cloud. Each of these could be running even in a separate cloud or different regions of the same cloud and notice too that we have introduced our SAS billing as a completely separate cloud managed service and so this is a cloud boundary we don't actually know where the billing system is running necessarily, but we do know that it is a managed service in the cloud, and we integrate with it. So here we're paying for a subscription, and this would, of course, be what? Yes, a generic subdomain. Whereas the interchange, the billing interchange, whereas the interchange, the billing interchange, is a simple component here that is used to translate anything that is put on the message bus by any of the other bounded contexts and translating that into something that the external billing system can consume. can consume. Choreography is a way of managing processes such that the different contexts become responsible for interpreting through domain events what has occurred previously and interpreting that to something that needs to happen next within their context. So for example, from intake or from underwriting, depending on where the applications are received, we're going to generate and emit a domain event named application submitted. This event is put on the bus, the message bus, and we are consuming that in the risk-bounded context. The risk-bounded context is not consuming the domain event internally into its model, internally into its model, but rather it's using an adapter in the ports and adapters architecture to translate that domain event into a command that is part of the ubiquitous language of risk. And this command is telling the risk assessor to assess a risk, and as a result, a risk-assessed event is emitted from risk as the third step. again, not being consumed directly into the domain model of this bounded context, but rather the rate team is translating this risk assessed to a calculate rate, and calculate rate or the rate calculator is emitting the event rate calculated. And rate calculated is then seen later by another component within underwriting. Now underwriting is in a position to generate a policy, for example, or generate a quote for a potential policy.