云巧工坊蓝图绘制简介

2022-10-27 493

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 根据领域驱动设计引子，引出事件风暴建模方法，划分限界上下文等战略设计方法。介绍云巧工坊提供的蓝图设计工具，帮助开发者将业务模型落地为代码架构。

PBC和业务建模

问题是什么

在软件行业，我们都知道一个经典的故事：用户想要一匹跑的更快的马，福特发明了汽车。

之前看到过一个段子，面对这个需求的时候，二逼产品经理已经开始喂马和给马制定健身计划了。那么面对客户直接的需求福特是怎么挖掘和定义问题的呢，我们可以想象下面的对话：

产品经理：你为什么需要一匹更快的马呢？

用户：因为我想跑的更快

产品经理：为什么想跑的更快

用户：这样我就可以更快的到达目的地了

所以，通过一定的分析和挖掘，用户想要一匹跑的更快的马的真实诉求是“更快，更短时间的到达目的地”，于是福特发明了汽车。

从PBC看组件的业务价值

Gartner在2021年10月19日，正式发布了2022年重要战略趋势。其中包括了“可组装式应用”这一战略。关于可组装式应用，Gartner提出了“PBC”（Packaged Business Capability）这个概念作为组装式应用的核心。

与微服务架构不同的是，前者交付的依然是封装应用，而基于PBC的组装式应用交付的是一个数字化的平台。在这个平台中，PBC更像一个个原子，而组装式应用是把这些原子重新组合起来的一个个分子。

对于业务问题的定义和理解直接决定了我们在解决用户问题时所采用方案。

通过领域建模和PBC式可组装应用，可以把我们对业务的理解、和技术架构的实施结合起来。

领域驱动设计

领域驱动设计(DDD：Domain Driven Design)是一种处理高度复杂域的设计思想，它试图分离技术实现的复杂性（Technical Concern)，围绕业务概念构建领域模型，来控制业务复杂性，以解决软件难以理解，难以演化等问题。领域驱动设计思想较其他建模方法更系统全面，其涵盖面包括战略上的模块拆分和战术上的应用内部架构。

领域驱动设计为达成业务建模目标提供了基础。

DDD设计思想

DDD核心是通过划分业务领域的边界，将复杂的问题，拆分为不同的领域，分而治之。

战略设计和战术设计

DDD提供了两种策略，战略设计和战术设计。

战略设计：通过划分边界（限界上下文）的过程，以及探讨不同边界的性质，实现策略的过程

战术设计：找出具体的业务概念，并且在特定架构约束下完成技术实现的过程

通过战略设计和战术设计，我们逐步分析，分解，获得解决方案中的领域模型，限界上下文及其映射关系。

事件风暴和领域建模

领域建模是比较常见的定义问题的方法，我们以“事件风暴”工作坊来梳理：旅行中“购买机票”的模型，感受一下面对业务场景，领域建模师如何帮助我们梳理问题的。

1）首先邀请领域专家参与进来，通过用户旅程图呈现整体业务流程。我们可以看到核心的步骤包括三部分：配置航班，预定，旅行，在每一个步骤中又有很多子步骤。将这些步骤列出来，并且标记处每一步对应的状态。

2）面对流程中我们会发现有很多的名词概念，和动词操作。我们把名词的部分找出来，就是“业务概念”，比如“航班”，“预定”，“机票”，“旅客”；同时，我们把对应的动词和产生动作的操作者也找出来，这些称为“命令”，通过命令对业务概念的操作，最终使得业务概念的状态变化，从而完成我们的业务。产生的结果我们通过状态描述，如：航班已创建。

命令的方式有多种：用户操作，系统行为，第三方系统行为，定时任务等等。感兴趣的朋友可以通过了解更多事件风暴的内容。

3）当我们梳理好一个个业务概念之后，接下来，把一个核心流程里相关的业务概念划分为一个限界上下文。不同限界上下文通过上下文映射相互调用。划分上下文没有标准答案，根据具体的业务场景和业务方向，可以是一个上下文，也可以是多个。并且，限界上下文的边界在业务的不同时期可能会发生变化。这些都可以帮助我们更好的理解业务。