其实关于产品架构的设计，我自己基于“领域驱动设计（DDD）”理念，创造了一套“一二三四”模型，不知是否具有广泛性和应用性，遂整理成文，并附加案例，供大家讨论并验证。
一、前言
作为产品经理，只专注于功能设计是不够的，需要清楚地了解产品的定位、要解决的问题、系统的组成、每个系统承担的角色以及未来的发展，因此对产品的架构能力必不可少。
但是随着产品的发展，出现了一些之前没有考虑到的需求，此时再去加新功能，难点不在于要怎么设计，而是如何兼容已有的设计，久而久之，产品逻辑会越来越复杂，牵一发而动全身，最终只能重构，不管是对设计还是对开发都是如此。
当我开始负责一条业务线的多个产品的时候，又发现不同产品之间会有相同的功能模块，但是他们是分别开发的，可能逻辑不同，也可能技术方案不同，造成这样原因有很多，比如沟通问题、制度问题等，但最重要的还是由于对新需求“打补丁”的方式导致产品越来越臃肿，一些共用的模块无法抽离出来，所以形成了重复造轮子的情况。
以上，让我越来越明白前期设计好产品架构的重要性，同时纠正了我的一个思想：产品架构设计是一个系统性的工程，不是随便罗列功能模块就能完成的。
于是我尝试跳出产品范畴，去看看旁边比我们先发展好几十年的开发领域，试图从中找到一些灵感。
近年来技术架构都在围绕“高内聚低耦合”的思想不断完善，从MVC、三层架构到微服务、中台、DDD，无一例外。
其实对于产品架构来说也是一样，在设计系统时不仅要考虑全面，还要考虑未来的可拓展性。
本文介绍了我在研究“DDD”后，借助其通过分解控制复杂性的思想，并结合自身经验总结的一套构建产品架构的方法论，我将其命名为“一二三四”模型。
二、一个【关键链路】
客观世界中，存在能量守恒定律，一种物质通过周围环境的影响会变成另一种/几种物质，但总能量不会变。如果我们把环境因素想象成一个黑盒，那么可以抽象出下图模型：
同理，我们将互联网产品也想象成一个黑盒，它并不会创造新事物，而是通过将事物线上化和协同化，并通过数据智能的方式加速“输入→输出”这一过程，从而为用户提升效率、创造价值。
任何一个产品不管它现在发展得有多庞大，都有且存在着一条关键链路，用来连接各实体。
比如在没有滴滴前，我们是靠运气打车，乘客和司机之间不存在其他的联系。
而滴滴是将周围的司机、周围的车辆和需要打车的乘客都联系在了一起，从而提升了打车体验。
尽管现在的滴滴已经不止“打车”业务，还发展了货运、顺风车、代驾、共享自行车、金融等其他业务，但都是在这条关键链路上，对输入和输出进行扩展。
所以在绘制产品架构图之前，应该先思考：你所负责的产品，它的核心链路是什么，连接了哪些实体？
这样做有两个好处：
例如在疫情当下，高校无法组织线下考试，因此需要做一个线上考试平台，即便你以前没有接触过教育信息化行业，你也知道考试的输入是考生、考官和试卷。
值得注意的是，产品的核心链路不是一成不变的，它会随着产品定位的变化而变化，比如下图是小红书历次slogan的变化，每一次定位的变更都意味着输入和输出的调整。
三、两个【思维】
找到了核心链路，接下来就是利用“分解思维”对核心链路进行梳理，并利用“聚合思维”对系统进行构建。
1.分解思维——6W2H
1）分解输入
回到线上考试系统，先按照上图的方法分析试卷：对于输入，我们要寻根溯源，思考它从哪来，如何来、与系统的关系等。
通过以上分析，我们新发现了两个实体：出题老师和题目，需要继续对其分解至最细（见下图），过程中可省略一些维度（考生、考官也按照相同的办法进行分解，此处略）。
2）分解输出
对于输出的分解思路会有少许不一样：我们要发散思维，思考它到哪去，如何去、如何扩大输出等。
同样对找出的实体用相同方法进行再分解：
至此，我们已经有了一个非常庞大的包含各角色、各事物及信息流转方向的对象关联画布。
2.聚合思维——划分子域
如果把我们面对的问题叫做“领域”，接下来，就要利用聚合的思想将一个或多个分散的实体封装为一个整体，使“领域”划分为几个“子域”（子系统）。
在领域驱动设计思想中，关于如何聚合可遵循以下四个原则：
翻译成产品经理能听懂的话就是：
因此对于线上考试平台可以做如下划分：
3.分解思维——界限上下文
在DDD中，对界限上下文的定义是：动态的业务流程被边界静态切分的产物。可以简单理解为再次利用分解思维把每个子域内涉及到的模块分解出来（此处不一一举例）。
4.关于该步骤的答疑
个人认为，本部分是本篇最重要也是最难理解的内容，因此有必要做一些解释。
四、三个【完善】
一个系统要想好用，有完善可拓展的功能只是第一步，还必须保证系统的稳定性和安全性。
这些不只是技术人员需要考虑的问题，产品经理也需要设计相应的产品架构、业务流程和功能逻辑来规避这些问题，有时甚至要牺牲用户体验。
在稳定性上，我们已经从业务的角度把一个大系统划分成了一个个高内聚、低耦合的小模块，接下来就要从运行维护的角度考虑如何检测预警以及出问题时的上报和解决。
此外还要找出所依赖的第三方服务，做好及时监控和应急方案，下图是我在网上找的通过设计维护稳定性的两个例子。
同样在安全性上，除了要保证基本的数据安全、网络安全，产品经理还要做一些提升安全性的设计，如二次认证、CA加密、二级密码等。
五、四个【层次】
至此，我们已经将整个业务划分出了多个领域（系统/模块），接下来就是纵向地对层次进行划分。
这里先介绍一下产品层面的三层架构（虽不是但源于技术层面）：
这种架构本身没有什么问题，但是如果站在更高的视角看整个产品矩阵，你会发现随着业务场景越来越复杂，每条业务线都会变得非常臃肿，并且业务线与业务线之间会存在重复造轮子的情况。
比如公司要做一个企业培训的新业务，其中题库、试卷模块可以完全复用考试系统（类似于技术开发中的“组件”“中台”概念），但在现有三层架构下不好进行抽离。
因此在设计产品架构时，还要根据产品经理的经验，对业务依赖性不高，通用性、复用性较强的子域单独抽离出来，组成新的一层——通用业务层。
至此，我们将上述步骤得出的结果进行整理，再找设计同事帮忙美化一下，即可得到下图：
六、总结
本文由@产品乱弹原创发布于人人都是产品经理，未经作者许可，禁止转载。