【多图预警】手把手教你用“DDD”的思维构建产品架构 ｜ 附详细案例

最近带的产品经理请教我如何思考并绘制产品架构图，他在网上看了一些文章，要么大段概念介绍，无法实操，要么不好理解，所以想问问我有没有什么经验。

其实关于产品架构的设计，我自己基于“领域驱动设计（DDD）”理念，创造了一套“一二三四”模型，不知是否具有广泛性和应用性，遂整理成文，并附加案例，供大家讨论并验证。

一、前言

作为产品经理，只专注于功能设计是不够的，需要清楚地了解产品的定位、要解决的问题、系统的组成、每个系统承担的角色以及未来的发展，因此对产品的架构能力必不可少。

当我刚开始负责一个产品的时候，对于产品架构的要求不是那么明显，觉得那只是换了一种漂亮的形式来展现系统中的功能。而且也不注重前期的规划，往往是要做相关的材料，才根据现有的系统反推架构。

但是随着产品的发展，出现了一些之前没有考虑到的需求，此时再去加新功能，难点不在于要怎么设计，而是如何兼容已有的设计，久而久之，产品逻辑会越来越复杂，牵一发而动全身，最终只能重构，不管是对设计还是对开发都是如此。

当我开始负责一条业务线的多个产品的时候，又发现不同产品之间会有相同的功能模块，但是他们是分别开发的，可能逻辑不同，也可能技术方案不同，造成这样原因有很多，比如沟通问题、制度问题等，但最重要的还是由于对新需求“打补丁”的方式导致产品越来越臃肿，一些共用的模块无法抽离出来，所以形成了重复造轮子的情况。

以上，让我越来越明白前期设计好产品架构的重要性，同时纠正了我的一个思想：产品架构设计是一个系统性的工程，不是随便罗列功能模块就能完成的。

我开始研究方法论，看了一些文章，每个人都有每个人的看法，但尚没有一种权威的理论作为支撑。

于是我尝试跳出产品范畴，去看看旁边比我们先发展好几十年的开发领域，试图从中找到一些灵感。

近年来技术架构都在围绕“高内聚低耦合”的思想不断完善，从MVC、三层架构到微服务、中台、DDD，无一例外。

其实对于产品架构来说也是一样，在设计系统时不仅要考虑全面，还要考虑未来的可拓展性。

本文介绍了我在研究“DDD”后，借助其通过分解控制复杂性的思想，并结合自身经验总结的一套构建产品架构的方法论，我将其命名为“一二三四”模型。

二、一个【关键链路】

客观世界中，存在能量守恒定律，一种物质通过周围环境的影响会变成另一种/几种物质，但总能量不会变。如果我们把环境因素想象成一个黑盒，那么可以抽象出下图模型：

所以在绘制产品架构图之前，应该先思考：你所负责的产品，它的核心链路是什么，连接了哪些实体？

这样做有两个好处：

1. 避免其他干扰，直击产品核心价值，类似于“第一性原理”；
2. 不需要对业务很熟悉，只要有产品定位，就可以得到。

例如在疫情当下，高校无法组织线下考试，因此需要做一个线上考试平台，即便你以前没有接触过教育信息化行业，你也知道考试的输入是考生、考官和试卷。

1）分解输入

回到线上考试系统，先按照上图的方法分析试卷：对于输入，我们要寻根溯源，思考它从哪来，如何来、与系统的关系等。

• what（属性）：试卷类型、分值；
• who（谁参与输入）：出题老师；
• when（什么时候输入）：考试前；
• where（从哪来）：题目；
• how（怎样输入）：创建、导入；
• how much（数量受什么影响）：考试方式。

通过以上分析，我们新发现了两个实体：出题老师和题目，需要继续对其分解至最细（见下图），过程中可省略一些维度（考生、考官也按照相同的办法进行分解，此处略）。

2. 聚合思维——划分子域

如果把我们面对的问题叫做“领域”，接下来，就要利用聚合的思想将一个或多个分散的实体封装为一个整体，使“领域”划分为几个“子域”（子系统）。

在领域驱动设计思想中，关于如何聚合可遵循以下四个原则：

1. 生命周期一致性原则
2. 问题域一致性原则
3. 场景频率一致性原则
4. 聚合应尽可能的小原则

翻译成产品经理能听懂的话就是：

• 实体A脱离另外一个实体B是否有存在的意义。例如如果没有考试，那么也就不存在考场
• 不属于一个问题域的实体不能放在一起。比如在线监考和在线考场，根据生命周期原则可能会把这两个实体放在一个子域，因为有正在进行的考场才需要监考，但实际上他们解决的是两个不同领域的问题
• 实体A和实体B能否被同时操作。以“试卷”、“考场”和“题目”为例，试卷包含了很多题目，这些题目会通过线上考场展示给每个考生。但是，站在操作层面，如果你要查看试卷列表，其实并不需要关心里面的题目，也不需要了解试卷所在的考场。尽管考务人员在编排考场的时候会查看题目以验证是否添加正确，但是大多数时候并不会去查看题目的分数，更不可能在创建考场的时候修改题目
• 剩余的实体均划分成单独的子域。
• 好的划分可以让整个系统更灵活，拓展性更高。但是也不能一味追求分化，需要根据自己业务的实际场景去衡量。还是拿题目和试卷举例，如果你的业务比较简单，只需要对试卷进行操作，那么可以把题目和试卷划分为一个“试卷子域”；如果你的业务复杂，试卷既可以直接创建，也可以通过题目组卷，那么就需要划分为两个子域“题库子域”和“试卷子域”。

因此对于线上考试平台可以做如下划分：

3. 分解思维——界限上下文

在DDD中，对界限上下文的定义是：动态的业务流程被边界静态切分的产物。可以简单理解为再次利用分解思维把每个子域内涉及到的模块分解出来（此处不一一举例）。

六、总结

• 一个关键路径：找出核心的输入输出；
• 两个思维：分解出各实体，聚合出各子域；
• 三个完善：考虑稳定性、安全性、第三方服务；
• 四个层次：按表示层、业务逻辑层、通用业务层、数据层划分。

本文作者 @产品乱弹 。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！