怎么通过前端的按钮定位到具体是哪个请求_微前端架构（Micro Front end）如何落地？...

大概在年初的时候，我发布一篇关于微前端架构的文章，收到很多反馈。这里我想大概再简单说一下如何在实际开发过程中选择微前端的架构。微前端架构发展到今天，其实已经比较成熟，虽然还有一些问题要解决。我身边的朋友以及公司，都在努力解决目前存在的问题。但是作为一名架构师，我们如何去选择适合自己业务或者公司部门的微前端架构呢？

一般我们做软件架构选择的时候，大部分时候我们关注至少三个方面，

• 业务需求
• 组织结构
• 开发人员的经验

搞清楚这些之后，我们开始选择实现微前端的具体过程。微前端有很多方法可以实现，那我们怎么去一步一步选择具体的方法来实现微前端呢？

大概可以从以下四个方面考虑，

• 识别微前端
• 构建微前端
• 微前端路由
• 微前端之间通信

识别微前端

让我们从第一个选择开始，这将对后面的决定产生重大影响。 我们需要从技术角度确定如何定义微前端，这里有2种可能的选择(如下图)：

• 水平拆分：一个页多个微前端
• 垂直拆分：每次加载一个微前端

在水平拆分方案中，当我们在同一页面上使用多个微前端架构时，多个团队需要协调工作，因为每个团队都负责视图(view)的一部分。

在垂直拆分方案中，每个团队都负责一个业务领域，例如 在这种情况下，通常将DDD原理应用于前端体系架构。DDD 中的另一个重要术语是有界上下文(bounded context)，它是一个逻辑边界，隐藏了暴露契约以使用模型中的数据的实现细节。通常，它将由域和子域定义的业务区域转换为逻辑区域，在这些逻辑区域中，我们定义模型、代码结构和我们的团队。有界上下文通过创建它们之间的契约来定义不同上下文之间的通信方式，通常由 API表示。 这允许团队根据预先定义的契约同时处理不同的子域。通常，在新的项目中，子域会重叠有界上下文，因为我们可以自由地以尽可能好的方式设计系统，因此我们可以将特定子域分配给一个团队，以交付