百木园
之前写过一篇文章《到底什么是B端产品的用户体验？》，用提问的方式道出了我个人对B端产品用户需求层次的理解。
用户体验是肉眼可见的一面，在B端产品里，还有看不到的一面——系统结构，它直接决定了产品重构的生命周期，直接决定这个系统设计的好与坏。
为何要如此夸夸其谈？
乔布斯小时候，他爸爸做一个橱柜，背面也用好木头。乔布斯十分不解：“背面又看不见，为什么还这么重视？”爸爸说：“看不见的地方与能看见的地方一样重要。”后来，乔布斯做苹果电脑时，要求里面的线路必须整齐。工程师把看不见的地方做得精致，已经超脱了产品本身，而是艺术之品，是对另一种追求。
同样，软件产品背面的木板也理应炮制有方，理之有序。即使我们作为凡夫俗子无法理解高境界的艺术境界去追求极致，至少也该对系统系统的重构周期尽可能长做出结构优美的设计。
一、什么是结构？
字典释义：由组成整体的各部分的搭配和安排。
如果您有阅读我的历史文章《系统是什么？》会知道，结构实则就是系统三大件（系统目标、组成部分、关系）中的关系，它随处可见：天体之间是万有引力，自然界是物质和能量交换，经济领域是价值交换，建筑领域是力学，系统领域则是逻辑等等。
二、结构为什么对B端产品如此重要？
图1 结构示意
1. 结构对系统形成稳定支撑
建筑结构基于力学的精密应用，承载摩天大楼历经风雨不塌；系统结构基于逻辑学的精密应用，承担B端产品的经久迭代可用。
这似乎也是架构师的核心使命：通过对复杂环境的信息收集，对信息进行分类归总，并赋予它们最优逻辑联系，最终建立秩序，从而支撑产品即使应对复杂外部环境的变化，也能支持持续的优化和升级。图1，左右两侧都构建出了支撑结构。
2. 结构是一种化繁为简
熵增定律：要让一切的无序变得有序，必须做功，如我们身体需要摄入能量支持新陈代谢做功，来保持有序（健康）状态。
系统设计一样，起初是一堆无序信息，经由智力做功，对其分类、归总、建模，终而形成简单且易于理解的结构，做功能效越高，结构越抽象越简单，且蕴含的势能也越大。
图1中，通过三条与边垂直的相交，且保持120°的直线形成内部结构，完全可以支撑“承重”，优美、简单、清晰；右侧的“承重结构”，但纷繁复杂，难以理解，明显是没有智力做功，或做功效率低下的结果（我们的系统何尝不是慢慢从左侧变成右侧）。
3. 结构有助于统一上下文
清晰简单，易于理解，会便于交流与思想同步。团队的配合的最高境界是“默契”。而结构何尝不能达到这个境界？给定一个输入，通过结构的逻辑链路就可以通过结构大致推断出一个输出，何须反复澄清？
4. 结构有助于查找问题
结构清晰，意味着构件的职责分工清楚，构件之间的逻辑关系明确。系统一旦暴露问题，通过表象就可直达问题根源，容易定位。
三、怎样才算是好的结构？
从图1中，结构的好与坏一目了然。
左侧，三条长度相等，相交120°，形成完整的“承重结构”，实用而美观。我们作为系统“设计师”，也多少要有一点艺术的极致追求，赋予系统结构些许的赏心悦目。
1. 清晰的系统目标
做系统一定不是为了做而做，而是有意义驱动，这个意义构成了系统目标，或者说是此系统的第一性原理。反过来说：如果目标不清晰或有所偏离，从根上就不正确，基于此构建的系统也必定是无效的，更无优美可言。
有时会存在目标尚不晰的情况下边干边看，来争取时间的场景。这时，需要依靠敏捷迭代来逐步保证目标的正确性（关于系统目标这部分，建议延伸阅读历史文章《“第一性原理”在B端产品设计中的运用》有更深入的讲解）。
2. 构件职责单一
“单一职责”原则，您应该多少有听过。无论是大到经济领域的专业分工，小到系统构件的单一职责，都是在讲避免“眉毛胡子一把抓”导致哪方面都做不好的情形。一个构件一个职责，十个构件便是十个职责，通过数个构件职责的相互关系便可以达成系统的整体目标。
这背后的原理也很简单：低维简单问题易于高维复杂问题。将高维复杂问题进行切割，到我们能够妥善处理的粒度，多个简单问题妥善解决后，复杂问题也就随之解决（来源于还原论）。
3. 构件关系简单
与其说简单，不如说弱依赖。在系统设计时，十分忌讳“强依赖”（A宕了，B就停止工作了），它是系统设计的灾难。
构件之间，尽可能做到少依赖、弱依赖：尽可能在A宕掉的时候，B还能自闭环地正常工作，这样客户的业务才可能不受阻碍，系统才会有一定的柔性。
想做到2和3极度不易但并非不能达到。在1的指导下，不断循环2和3，直到纳什均衡（没有任何可以改进的空间），其结果便是构件职责分工清楚，构件之间的依赖极少或者极弱。
四、怎么做好结构？
做好结构，基本等于做好系统。还是离不开系统三要件：系统目标清晰、构件职责单一、构件关系简单。
既然好的结构是严密的逻辑推导，那么也不得不使用科学的方法帮助实现。这里就不得不提及应对复杂系统设计的方法论：领域驱动设计（DDD，Domain-Driven Design），这并不是什么横空出世的新鲜玩意儿，这是Eric Evans在2003年就提出的一个近20年的设计思想，其核心目的是解决复杂软件架构设计。
对于复杂的B端产品，DDD的设计思想再合适不过，但要领会其中的要义，也并非一日之寒。
DDD包含战略和战术两大部分内容，对于B端产品经理，建议掌握战略部分：商业逻辑、核心业务流程设计、用例设计、实体识别状态图设计、领域模型设计、限界上下文识别机映射的设计。
由于DDD是套体系方法论，限于篇幅，本文仅能对推导逻辑，进行简单介绍，建议延伸阅读此大佬的系列文章，当然也可私信交流，若有必要，我也可以后续撰专文介绍。
DDD战略设计实战方法逻辑：
1）商业画布确定商业逻辑
商业模式画布理清供与需的匹配关系。
- 根据细分客户（CS）的价值诉求，确定供给的价值主张（VP），价值主张成为连接供需关系的衔接点。
- 发挥核心资源（KR）及重要合作伙伴（KP）的能量，，策划自己的关键业务（KA）。
- 关键业务需要涵盖，触达细分客户的渠道通路（CH），以及客户关系（CR）的手段及方式，达到让客户接触到价值主张，并持续认可，甚至增值的目的。
- 支撑这一切活动的底层离不开ROI的科学测算，包含收入来源（RS）和成本结构（CS）。
2）明确系统愿景
在1的内容中，梳理出这件事情的利益干系人，每个利益干系人都有在这个系统中的角色及心理目标，整合这些目标，形成系统愿景。并将愿景拆分成不同阶段实现。
3）串连核心场景
有了1和2，可以策划解决方案。识别出几个关键的场景，将它们串连形成闭环的解决方案。
4）拆解每个核心场景
3中识别出来的关键场景理应都是自闭环的场景，所以也理应有自己的运作业务、角色以及用例，尝试用流程图和用例图两个视角将其表达出来。
5）识别核心业务时标对象及状态流转
在拆解核心场景时，一定会涉及到业务单据，将其记录下来，若单据有跟随时间、事件、动作发生状态转移，则需要绘制出它的状态图。
6）理清业务对象之间的关系
除了5中的业务单据，还有其他的的业务对象，识别出来后，通过领域模型（Domain Model）表达出他们之间的关系，以让开发同学一目了然。
7）限界上下文与上下文映射
这部分较难，且更偏重技术的服务拆分，也是DDD中“高内聚，低耦合”思想的重要呈现。但对产品经理而言，是“nice to have”，并非必须，有兴趣的产品经理可以进一步掌握。
1-6，更偏商业逻辑到用户相关的业务信息的梳理。这部分的清、干净、闭环地呈现，对架构师往后的设计以及工程师的编码工作具备十分具有指导意义。也就是说，1-6的优美，引导着整个系统结构的优美。
五、总结
万物皆系统，系统内部定有工作结构。天造系统，窥其结构，十分优美，经久不衰；人造系统，理应学习，讲究结构，方可存活长久。
无论是系统延续需要，还是设计者的造诣追求，结构都应该精致优美。
科学的方法是保证这一切得以实现的基础。个人认为DDD是目前较为合适B端复杂产品设计的方法论，但理解不易。
欢迎我们一起学习探讨，愿企服领域有了我们发展更好。
本文由 @推石头的JC 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
来源：https://www.woshipm.com/pd/5578146.html
本站部分图文来源于网络，如有侵权请联系删除。