Challenging questions foster growth and I really appreciate those who challenge my ideas. It helps me grow.
The presentation of the UI does not have to have anything to do with where you divide your SCS. Have you ever used Pluralsight? I challenge you to figure out which screens are part of which SCSs. When I left in 2017 there were like 15 SCSs — I hear there are even more now.
There are several strategies to make your app look unified even though it is made up of multiple SCSs. One is to create a design language where the designers agree that a button looks like this and there is this much space between these types of elements, etc. In your example if planning the trip and ordering the trip are on separate screens then this is easy. Your two teams develop their SCS as vertical slices then you use a reverse proxy (e.g. an ALB in AWS) to make the URL magic happen. The user thinks they are using one application when in reality there are two web applications that look like one web application.
If your UIs are a little more coupled then you can use web components at the coupled points.
The decision to split off an SCS is 100% around reducing communication costs. At a certain team size it becomes hard to communicate. You start having merge conflicts, you have to create a bunch of standards so your code doesn’t turn into chaos, you have to make decisions about tech stacks and dbs, etc. When these activities become too expensive, your team is too big. Amazon famously said a team should never have more people than can eat two pizzas for just these reasons.
The SCS architecture is all about providing a light layer of required communication protocols and standards and delegating every other decision down to the individual SCSs.