> SCSs should ideally not communicate with each other > SCSs should favor integration at the UI layer. Not sure how to make sense of this... so you have compo

> SCSs should ideally not communicate with each other > SCSs should favor integration at the UI layer. Not sure how to make sense of this... so you have components that are not allowed to talk to each other and are all integrated through a UI layer. For systems that don't need to communicate between each other I'll claim is not where we're having troubles managing complexity. You may start of thinking you're build a SCS and then what happens when a requirement arrives needing two SCS to communicate? I guess it's some sort of monolith? Maybe reach for your enterprise integration patterns to help make stitching these easier. If you have two independent services, why would you even think to build them as a monolith? Probably not a good idea to build your corp wiki software in the same monolith as your payroll system. One benefit I see from this specification is that it helps frame the conversation around a service architecture allowin g you to draw boundaries around services that define this concept of a SCS.