业务模块在你做之前，一定要多想呀？

需要吸取上几次编辑文字，无法往下推进去的教训。需要先简单概要描述，目录结构是怎么样的？

产品工作过程，抽象到具象，再抽象到具象，如此这般，我们会反复思考，不停对自己诘问。自我怀疑的终点，是在产品落地，获得反馈的时候，不管是正向还是反向的反馈，他们都是一个结果。产品经理需要坚持的事，不断的做正确的事情。如何做正确的事情？穷尽问题和分类，细化，分类，梳理整体、部分，整体和部分的关系，定义与概念。

我们在做产品业务定义的时候，首先我们要划分几个大的类目，这在系统架构，技术架构里面，就是传统的三层架构，是最经典的；再往下分，是业务模块，相同或近似业务的整体；再往下分，是每个业务模块的流程，需要分几步去实现这个业务，每个步骤或流程，再抽象就会变成功能，功能具象化就是页面或接口；再每个业务模块、业务流程中间，是不是还有很多空隙？他们之间怎么联系？怎么进行组合？也是我们需要去考虑的。这篇文字，还会介绍两种产品业务定义的方法论，思考方式，一种是来自传统的，或产品常用的，UML；另外一个是相对较新的，技术人员去思考的，DDD，领域设计方法。以上三点，我们还可以细化讲，单独称为某个课程，能讲个皮毛，提供一种启发吧。

业务模块

系统、技术架构里面大都会分为三层架构，上下都是相对较薄的，中间是具体的业务模块，简单来看，最上层的是前端，用户层，终端，面向具体用户的呈现；最底下的部分是公共的通用的模块，通用的能力，所有业务都会用到的，为业务服务的部分。中间的业务模块，有的是通过场景，用户角色来划分，例如我所有的用户都是在一个终端上面操作，或者是每个用户都是在多个终端上进行操作之类的；有的产品的业务跨度非常的大，他要做覆盖整个商业服务，或内容服务，或我就要做一个工具集合的服务，那就要划分不同的行业，或是不同的品类标签了。

我们之前提到的 title“业务架构师”，他需要有技术背景，能和技术经理，开发的架构师去配合输出，业务需要和技术，用户、场景深度绑定，嵌合在一起的，脱离用户场景谈业务，或脱离技术实现去谈业务，都是不实际的。也就是我们常说的 PPT 式样的架构师。那我自己的能力程度来讲，我的层次可能就是在 PPT 式样的业务架构师，我对技术的理解，背景确实还是不太够的。

用户权限认证中心，用户角色，身份有很多不同的场景，场景之间的关联跨度比较大；用户的身份或角色具有敏感性，需进行背书等情况，可在用户层(终端)外罗列权限认证中心。特殊行业，例如医院、教师等，权限认证中心，存放用户身份的背书相关证明，并有审核流程。案例：医疗设备厂商，需要用医院的医生使用反馈，患者的体验感受来指导设备的生产，优化设备的设计。平台就有两部分服务，一部分商业服务，代理商、电商平台，B2B(代理商卖设备给到医院)，F2B(设备厂商直接卖设备给到医院)；内容服务，内容社区，考试和数据系统，都是垂直行业领域的，而且非常的“垂”，细分领域了。针对的事心电设备的商业平台，通过绿光来观察，感知血液流动，波动变化的单一采集数据的消费电子的设备是无法用的，通过多贴片，电极，多渠道数据进行综合的数据分析，整合图形的设备；主要面向的是影像图谱，心外等医院科室。需要医生有相关的执照，设备厂商也要有“医”字号的资质(“健”字号不行)，对平台数据准确，数据稳定性有非常高的要求，毕竟这是关系一条活生生的生命的产品。

针对不同的业务，终端也可划定不同的应用，最好是一个身份角色来操作一个应用，操作和权限才更方便，更容易梳理。之前经历过用用户角色来确定应用的.案例 1:设备厂、代理商都在 PC 浏览器端，通过不同的域名地址进入，并且相互之间有链接跳转，接口数据传输；商户和商户员工在一个应用，消费者下单是一个应用，编外人员接单和服务又是另外一个应用。网站好说，就两个门户入口；主要是 App，有 3 个，每个 App 又要去打包两个不同的平台，整个版本迭代，应用更新成本，就不是当时我们所能承受的，需求线也发散。

案例 2:内容垂直服务，产品卖点和特点是打造千端千面，产品的终极形态目标是类似“某宝”那般，每个用户看到的内容都是不一样的。按照这样的目标，收集用户行为数据是需要提前布局的。而我们当时面对的行业是一个特殊的行业，政务平台，只能通过不同的场景去推送不同的内容。根据他面向内部和面向外部的两个场景，将一个网址里面划分两个不同的业务模块，一个是融媒体，一个是活动课程应用；再根据他设备非常多的特点，增加了设备物联平台，介入相关的数据。

对于业务模块的拆分，依赖的你对行业的观察，产品经验，你的世界观是怎么样的，不仅要有很像的理性分析的思维，更要有感性和细致的观察，洞察能力。业务需要概念，抽象，而这个抽象的概念要有价值，能够落到实际的商业模型，用户心智上面去。2023 年前后的这四五年，抽象和概念已经拉不到投资了，靠 PPT 式样的业务架构，基本很难存活，需要靠实际的价值和资源来支持。业务需要虚实结合，虚指的还是我们讲的“画饼”，为什么要做这个事情；实的是他能够提供什么价值，服务过程中会产生什么附加价值。虚实结合是必须的，只是现在更看重的价值。

上面用多个案例去分析业务架构、业务模块，其一是侧重点，其二是这部分你很难教会，学会，和我之前文字里面提到的事一样的，靠的是自己去“悟”，感受。靠的不是能力，而是你自己的，天赋是一方面，最重要的还是你想的过程和时间。用现在《三体》里面，最常的一句话，也是曾经我钉钉上面的签名，“北海呀，在这之前，你要多想”，我只能告诉你，要所想。