我最近带来的产品经理让我教我如何思考和绘制产品架构图。他在网上看了一些文章，不是很大的概念介绍，不实用就是很难理解，所以想问问有没有经验。

其实在产品架构的设计上，我基于“领域驱动设计（DDD）”的理念，创建了一套“一、二、三、四”的模型。供讨论和验证的案例。

一、前言

作为产品经理，仅仅关注功能设计是不够的。要清楚地了解产品的定位、要解决的问题、系统的组成、各个系统的作用以及未来的发展。因此，产品的架构能力必不可少。

刚开始负责一个产品的时候，对产品架构的要求不是很明显，我觉得只是一个漂亮的形式来展示系统中的功能。并且不注重前期规划，往往需要在按现有制度推回结构之前做好相关材料。

但是随着产品的发展，也有一些之前没有考虑到的需求。添加新功能时，难点不是如何设计，而是如何与现有设计兼容。久而久之，产品逻辑会越来越复杂，影响全身，最终只能重构，不管是设计还是开发。

当我开始负责一个业务线的多个产品时，我发现不同的产品会有相同的功能模块，但它们是分开开发的，可能有不同的逻辑或不同的技术方案。这就是原因。有很多，比如通讯问题，系统问题等等，但最重要的是，由于“打补丁”新需求的方式，产品越来越臃肿，有些共享模块无法提取，从而形成了反复造轮子的局面。 .

以上让我越来越意识到前期设计一个好的产品架构的重要性，同时也纠正了我的一个想法：产品架构设计是一个系统工程楼宇自控扩展模块，不能由人来完成。简单列出功能模块。

我开始研究方法论，看了一些文章，每个人都有自己的看法，但没有权威的理论支持。

所以我试图跳出产品类别，看看比我们早了几十年的开发领域，试图找到一些灵感。

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

事实上，产品架构也是如此。在设计系统时，不仅要考虑全面性，还要考虑未来的可扩展性。

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

二、一个[关键链接]

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

同样，我们将互联网产品想象成一个黑盒子，它不会创造新事物，而是通过将事物联网并与数据智能协同作用来加速“输入→输出”的过程。一个提高效率和为用户创造价值的过程。

任何产品，无论现在有多大，都拥有并存在一个连接各个实体的关键环节。

比如在滴滴之前，我们靠运气打车，乘客和司机之间没有其他联系。

滴滴通过连接周边司机、周边车辆和需要打车的乘客来改善打车体验。

虽然滴滴现在不仅有“打车”业务，还发展了货运、网约车、代驾、共享单车、金融等其他业务，但都在这个关键环节上，进行输入和输出。扩展名。

所以在画产品架构图之前，你应该首先思考：你负责的产品的核心环节是什么，连接了哪些实体？

这有两个好处：

避免其他干扰，直击产品核心价值，类似于“第一原则”；不需要对业务非常熟悉，只要有产品定位就可以搞定。

比如当前疫情下，高校无法组织线下考试，需要搭建线上考试平台。即使你之前没有接触过教育信息行业，你也知道考试的输入是考生、考官和试卷。

值得注意的是，产品的核心环节并不是一成不变的，它会随着产品定位的变化而变化。比如下图就是小红书之前的变化。每次定位变化意味着输入和输出。调整。

三、两个[思考]

找到核心环节，接下来就是用“分解思维”梳理核心环节，用“聚合思维”构建系统。

1.分解思维——6W2H

通过第一步，我们找到了与系统相关的最直接的输入输出实体，下一步就是分析实体与实体、实体与系统之间的关系。最全面有效的方法是6W2H：

1）分割输入

回到线上考试系统，先按照上面的方法分析试卷：对于输入，我们要追根溯源，想想它是从哪里来的，怎么来的，和系统的关系。

通过上面的分析，我们发现了两个新的实体：创建问题的老师和问题，需要分解到最小的细节（见下图），过程中可以省略一些维度（考生和考官也采用同样的方法）分解，此处省略）。

2）分解输出

输出的分解会有一点区别：我们需要发散思维，想想它去哪里，怎么去，如何扩大输出等等。

用同样的方法重新分解找到的实体：

此时，我们有一个非常大的对象关联画布，其中包括角色、事物和信息流的方向。

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

如果我们面临的问题叫做“域”，那么，我们必须使用聚合的思想，将一个或多个分散的实体封装成一个整体，从而将“域”划分为若干个“子域” （子系统）。

在领域驱动的设计思维中，如何聚合有四个原则要遵循：

生命周期一致性原则、问题域一致性原则、场景频率一致性原则、聚合原则尽量小

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

因此，在线测试平台可以分为以下几类：

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

在DDD中，有界上下文的定义是：动态业务流程被边界静态分割的产物。可以简单理解为用分解思维对各个子域所涉及的模块进行分解（这里不一一）。

4.关于这一步的问答

在我看来，这部分是本文最重要，也是最难理解的部分，所以有必要做一些解释。

我从 0 到 1 做了几个产品。在进行用户调研之前，我会先预想可能的业务流程，然后通过调研进行验证和补充。因为没有相关业务经验，提前思考的过程不会全面。在这种情况下，我开始寻找一种快速熟悉业务的方法。

在不断总结经验后，发现任何一个产品都会只关注一个基本问题，所以我直接从这个基本问题入手，找到相关的输入输出，然后通过各个维度的不断分解，不仅可以我找到了所有涉及的所有实体和流程，同时还找到了它们之间的联系（业务流程）。干部不妨一试。

四、三个【完美】

一个系统要想好用，功能齐全、可扩展只是第一步，还必须保证系统的稳定性和安全性。

这些不仅仅是技术人员需要考虑的问题，产品经理还需要设计相应的产品架构、业务流程和功能逻辑来规避这些问题，有时甚至会牺牲用户体验。

在稳定性方面，我们从业务的角度将一个大系统划分为高内聚、低耦合的小模块。接下来，我们将从运维的角度来考虑如何进行预警和问题出现的时间。升级和解决。

此外，我们需要找出我们所依赖的第三方服务，并及时做好监控和应急预案。以下图片是我在网上找到的两个通过设计保持稳定的例子。

同样在安全方面，除了保证基本的数据安全和网络安全外，产品经理还需要做一些提高安全性的设计，比如二级认证、CA加密、二级密码等。

五、四个[级别]

至此，我们已经将整个业务划分为多个领域（系统/模块），接下来就是纵向划分层级了。

我们先介绍一下产品层面的三层架构（虽然不是从技术层面）：

这个架构本身并没有什么问题，但是如果从更高的角度看整个产品矩阵，你会发现随着业务场景越来越复杂，每个业务线都会变得非常臃肿，业务线会很臃肿。业务线之间会有重复的轮子。

比如公司想做一个企业培训的新业务，其中题库和试卷模块可以完全复用测试系统（类似于技术开发中的“组件”和“中间阶段”的概念)，但在现有的三层架构下很适合提取。

因此，在设计产品架构的时候，还需要利用产品经理的经验，将业务依赖度不高、通用性和复用性强的子域分离出来，形成一个新的层——一般商务楼层。

至此，我们整理了以上步骤得到的结果，然后请我们的设计同事帮忙美化，可以得到如下图：

六、总结

本文由@原创发表，人人都是产品经理，未经作者许可，禁止转载。

题图来自，基于CC0协议。