微服务是从认知负载角度划分的，每个团队都是由人组成的，人都是认知能力限制或天花板的，这些决定了团队的认知能力大小，一个团队不可能建立或管理其认知能力之外的领域上下文知识，也就无法建立和管理相应的微服务，认知负载边界=微服务边界。
根据康威定理，组织架构决定了技术架构，那么就要逆康威定律，如果你想要一个微服务架构，那么就改造你的团队结构，这就是团队拓扑的由来，团队拓扑由四个团队组成：业务流对齐团队，这与有界上下文（限界上下文）对应对齐的，其他三个都是支持性团队，其中平台团队类似Devops团队，其他支持性团队在时间上不是永久捆绑在上下文里，而是对所有流对齐团队提供支持。
那么平台团队比较特殊：
事实上，我们创建了一个平台团队，因为其目的是减少团队在特定部分的认知负担。
但是，根据最近的学习，我们认为它本身可能是一个有界上下文，至少是一个支持子域。
这是对同一问题空间使用不同视角帮助您找到最佳团队组成的情况之一。
帮助我们识别这种情况的原因是使用 Big Picture Event Storming（战略图事件风暴） 来促进对部落（特殊的团队）识别新业务能力的快速学习：关于我们正在研究的领域的缺失知识，并且是重要的知识。
有趣的是，起初，平台团队似乎是为了减少认知负荷，后来演变成一种支持性的能力，这种能力如果涉及业务以 SaaS方式提供服务，那么可将平台作为一种产品和支持性的上下文来共享。
也就是说：流对齐团队通过平台SaaS共享平台团队的能力，不再需要人工现场配合工作了。
但是，如果平台团队是通过平台工程这样的运维工程提供 CI/CD或基础设施DevOps能力，则不属于业务。
banq观点：团队拓扑中只有流对齐团队才涉及业务流，工作在限制的上下文BC中，其他团队或提供业务内的除了核心子域以外的支持，或提供业务外的IT平台性技术服务。但是，对于平台团队内部，可以将平台作为产品来实现，这就属于平台工程，当然还有为流对齐团队提供支持的大数据团队，他们如果也有自己的平台产品。所以，团队拓扑中，如果其他支持团队能力强，认知能力好，可以通过打造产品的形式与流对齐团队合作，替代人工合作，无论人工还是产品API集成，都属于上下文映射范畴需要考虑设计的。