

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 识别微前端边界
<a name="micro-frontend-boundaries"></a>

为了提高团队自主权，可以将应用程序提供的业务功能分解为几个微前端，彼此之间的依赖性最小。

按照前面讨论的 DDD 方法，团队可以将应用程序域分解为业务子域和受限上下文。然后，自治团队可以拥有其受限上下文的功能，并将这些上下文作为微前端交付。

定义明确的有界上下文应最大限度地减少功能重叠以及跨上下文进行运行时通信的需求。可以使用事件驱动的方法实现所需的通信。这与用于微服务开发的事件驱动架构没有什么不同。

架构良好的应用程序还应支持新团队在未来交付扩展，从而为客户提供一致的体验。

## 如何将单片应用程序切成微前端
<a name="monolith-slicing"></a>

[概](introduction.md#overview)述部分包括一个在网页上识别独立功能上下文的示例。出现了几种在用户界面上拆分功能的模式。

例如，当业务域形成用户旅程的各个阶段时，可以在前端应用垂直分割，即用户旅程中的视图集合作为微前端交付。下图显示了垂直分割，其中 “目录”、“结账” 和 “发票” 步骤由不同的团队作为单独的微前端交付。



![每个微前端都有标题、目录、订阅详细信息和页脚。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures-vertical-split.png)


对于某些应用程序，仅靠垂直拆分可能还不够。例如，可能需要在许多视图中提供某些功能。对于这些应用程序，您可以应用混合拆分。下图显示了一种混合拆分解决方案，其中 Station finder 和 Route Explorer 的微前端都使用地图视图功能。



![Station finder 的 Team Discover 和 Route Explorer 的 Team Route 都使用 Team](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures-mixed-split.png)


门户型或仪表板型应用程序通常将前端功能整合到一个视图中。在这些类型的应用程序中，每个控件都可以作为微前端交付，托管应用程序定义了微前端应实现的约束和接口。

这种方法为微前端提供了一种机制来处理诸如视口大小、身份验证提供程序、配置设置和元数据之类的问题。这些类型的应用程序针对可扩展性进行了优化。新团队可以开发新功能来扩展仪表板功能。

下图显示了由三个独立团队开发的仪表板应用程序，这些团队是团队仪表板的一部分。



![当前的多团队仪表板应用程序，未来团队可能会推出新功能。](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures-team-dashboard.png)


在图中，future 视图表示新团队为扩展团队控制面板和仪表板功能而开发的新功能。

门户和仪表板应用程序通常通过在用户界面中使用混合拆分来组合功能。微前端可通过定义明确的设置进行配置，包括位置和大小限制。