2009–2013年在北航读本科，选了软件工程这个专业。那个时候其实也不太清楚软件工程和计算机有什么区别，大概软件工程轻松比较多。本科的课程都差不多，C++、数据结构、算法导论、计算机体系结构、计算机网络、操作系统原理、软件工程、职业生涯规划。毕业时正好赶上移动互联网和万众创业的浪潮，抱着改变世界一点点的想法，成为了一名的产品经理。
近几年工作中的不设边界，让我有机会接触了很多不同的知识体系。从产品、设计、运营到客户端、前端、后端、运维、架构再到管理、业务、投资，也有机会负责完整的产研团队。业务覆盖了2C、2D、2B、2G多个方向，包括数字城市、物联网平台、SCRM平台、海淘电商、商品导购、轻博客多个领域产品。
参考学习资料：
关于产品：
关于设计：
关于技术：
关于DDD领域驱动设计：
关于数据中台：
郭忆：数据中台实战课
本文将按照业务认知、软件工程、架构设计、领域驱动设计、中台体系、参考产品方案等依次展开，内容侧重在于骨干知识体系梳理，细节知识可以阅读推荐的参考资料。
一、关于业务认知1.业务是所有一切的根源
业务、产品、设计、技术是构建产品的四个核心元素。当我们想要做一个产品时，出发点都是为了解决一些问题。业务定义了问题是什么，产品定义了提供的解决方案，设计与技术支撑解决方案的实现。在我们的产研团队中也存在着业务负责人、产品经理、设计师、工程师与之对应。从上下游关系来看，产品的设计依赖于业务，而设计、技术的设计又依赖于产品。因此业务的变动是推动产品变动的核心因素，良好的产品架构应能快速响应业务的变动。
2.知识是从业务到产品的关键
3.知识积累是抽象到具体的过程
大家应该都有用过思维导图类的工具，知识的描述是从抽象到具体的。我们认知一个业务领域都是从主干开始，再到对应的枝杈模块，最后才是叶子细节。从小到大我们学过大量的知识，而在今天你很难对每个细节都记忆犹新，整个知识体系就像一个脉络地图，我们只记得枝干和重点的细节。当需要了解某个特定细节时，由于对枝干有清晰的认知，可以快速找到相应的细节信息。
4.业务的知识散布在各个环节
5.知识的分拆与职能的分工
当我们以横向：业务、产品、设计、技术，纵向：架构、模块、细节来将知识体系去做拆解，可以得到下面一张表格。
横向看每个知识层次的各职能岗位间有很多的协同，业务、产品、设计、技术跨职能的知识体系碰撞融合是产品深化的关键，相同的业务领域知识背景也让沟通交流更顺畅。
6.内聚知识的功能特性团队
我们常见的团队组织模式是职能型的，产品经理输出产品方案进行组内评审，再流转给下一个环境的设计团队，最后在流转给工程师团队。这种模式会面临几个显著的问题，一是各团队负责人会接收大量的知识细节成为瓶颈点，二是由于缺乏跨职能部门的知识共享交流容易出现认知偏差，三是由于某个功能模块相应的人员配合关系不稳定，导致知识弥散在团队中，几个人都知道一部分但又都不完整。
若我们按照功能特性式来进行虚拟团队划分，每个团队成员对负责的业务板块有差不多的业务认知，更有利于业务的推进和深化。在业务可拆分进行持续迭代的情况下，按照功能特性划分团队推进业务，职能线跟踪人员管理和专业培养，是大型团队管理比较好实践方案。
小结：
二、关于软件工程1.软件工程的起源
20世纪60年代由于计算机技术的飞速发展，软件系统的规模越来越大，复杂程度也越来越高。而早期的软件开发者大多是以充满了黑客精神的个人为主，在面对大型软件项目时需要大团队协作就出现了多问题，导致项目交付频繁延期，问题频出。这就是所谓的软件危机，为了解决问题在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工程的概念。
2.软件工程的发展过程
1）大爆炸模型
2）瀑布模型
软件工程从其他工程学例如土木建筑中吸取了很多经验，人类已经可以造成出非常宏伟的建筑，管理极其复杂的功能，通过早期尽可能详尽设计，来避免后续工程施工过程中问题。随着软件研发的工程化出现了瀑布模型，完成前一项工作在进行后一项工作，如果前项工作完成的没有问题，那么后面就会很顺利。
3）改进瀑布模型
我们很难一开始将设计都做的特别正确，所以会出现到了下一个环节发现需要对上一个环节进行修正，于是对瀑布模型做了改进，允许下一个环节的反馈来修正前一个环节。
4）快速原型模型
但现实往往是残酷的，除了设计缺陷外还经常遇到项目到了测试环节，才发现做的一些东西并不符合客户的预期，导致大量的资源浪费。于是在前面又增加了原型环节，用低成本来验证所做的东西是不是符合客户的预期。
5）增量与迭代
瀑布式的研发方式，虽然利用了工程化的方式改善了软件研发过程，但没有解决一个问题就是需求的变动。
通过增量与迭代两种方法，可以降低需求变动带来的影响。增量是将功能进行拆分，先实现其中一部分，分批交付。迭代是将功能先进行简单的实现，实现快速交付。参考二八原则，系统内大部分功能的使用频次是很低的，可以将资源尽可能优先用在高频的功能研发上。
6）精益与敏捷
敏捷与精益这两者很相近，要说差异大概在于精益的核心是避免浪费，敏捷的核心是快速响应。涉及知识体系较大，详细内容就不在此处赘述了。
3.核心理论与定律
1）盖尔定律
“一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行，无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。”
这与产品构建MVP策略是相同的，我们很难一开始掌握全局和所有细节，一上来就做很宏大的设计会付出惨重的代价，我们要做的第一步是先让东西run起来。好的架构设计可以让我们再后面的完善过程中不会推倒重来，这种思路也叫渐进式设计。虽然保持了持续交付价值，但是每一代产品基本都推倒重来，在做大型业务时要避免这样的方案。
2）没有银弹
这篇是一篇经典的论文《没有银弹：软件工程的本质性与附属性工作》，文中提出的核心观点：“所有软件创作都包括了本质性工作和附属性工作，本质性工作：即如何从抽象性问题，发展出具体概念上的解决方案；附属性工作：将概念上的构思施行于电脑上，所遭遇到的困难。软件工程面临的问题在于我们即使清除了大部分的次要复杂度，而剩余的主要本质性工作带来的复杂度都无法改变。”
了解DDD领域驱动设计，可以将业务域可以划分为核心域、支撑域、通用域三类，我们的资源重点投入在核心域上，支撑域、通用域的部分内容可以考虑外采标准系统和找第三方定制开发来解决。
3）复杂性守恒定律
“每个应用程序都具有其内在的、无法简化的复杂度。无论在产品开发环节还是在用户与产品的交互环节，这一固有的复杂度都无法依照我们的意愿去除，只能设法调整、平衡。”
很多的中后台系统中很多表单会存在大量的配置项，这些配置项是否可以简化，让平台变得更简单智能？大部分时候答案都是否定的，过度追求简化往往容易弄巧成拙。功能逻辑易于解释与理解才是更好的方案，当你试图简化降低复杂度，可能在其他地方埋了雷。
4）人月神话
随着人员的增加，团队内沟通成本会呈指数增长。公式：沟通成本=n(n-1)/2。
因此在软件开发后期追加人员，由于沟通成本的上升，可能不会提速反而会更严重的延期。
任务根据特点可以拆接为4种类型，不同类型的“人与月”的曲线存在差异。
软件研发属于关系错综复杂的任务，没办法像搬砖一样加人就提高效率。当我们不断的拆分任务与团队后，任务的复杂性会降低至需要沟通的可分解任务。
5）高内聚低耦合
高内聚低耦合是软件设计的基本原则，大量的方法论都基于此衍生发展。假设将问题或者任务拆解成关联比较弱的两个部分，一个复杂的大问题就变成两个没那么复杂的问题，整体的复杂度就降低了。因此这一方法论是降低复杂度的关键方法，不仅适用于软件设计，也适用于团队管理。
在业务认知一节中有介绍通过对业务、知识的拆解，可以降低团队成员的认知负荷。拆解结果符合业务子域内的高内聚，业务子域间的低耦合，就是好的拆解。功能特性团队在高内聚的业务子域中具有更高的协作效率，团队间业务的低耦合降低沟通成本。
6）康威定律
“产品结构反映了设计该产品的组织的沟通结构”，团队的结构影响会体现在产品上，组织架构会影响业务、产品、技术、设计等多个方面。
业务架构推导出产品架构，产品架构推导出技术架构和数据架构。组织架构会对一切造成影响，匹配的组织架构是落地好业务架构和技术架构的重要因素。
软件工程的本质是管理复杂性，按照分而治之的思路高内聚低耦合将业务、团队进行拆解，降低团队成员完成任务的认知负荷。部分业务模块采用行业内第三方标准方案，是降低复杂性的一种很好的途径。《软件设计的哲学》一书中提出复杂性来自于依赖和模糊的积累，好的设计最重要的目标之一就是让系统变得显而易见。
软件研发的发展是全行业的逐步沉淀过程，早期的数据分析需要自己搭建工具，再后来通过简单埋点使用标准产品就能实现。整个过程是设计思路的共识->技术方案的共识->第三方标准产品，即统一思路降低理解难度，复用行业通用开源方案降低理解难度，使用第三方产品再大幅降低理解难度。
三、关于各种架构1.架构的定义
我们打开搜索引擎搜“架构图”，可以看到各式各样五花八门的图片。它们大致像下图一样，整张图划分了很多个小区域，每个小区域里有一些内容，可能区域间箭头线段联系着。到底什么是架构？参考百度百科：架构就是对结构和组件的描述，可以让大家快速理解整个体系，指导一系列的细节设计。
2.架构的种类
我们经常会听到很多不一样的名词，方案架构、业务架构、应用架构、产品架构、技术架构、部署架构、信息架构。针对不同的视角维度，我们想要表达的结构和组件是不同的，因此存在不同的架构描述。
常见的一些架构维度：
3.产品架构设计
产品架构设计从了解业务流程开始学习业务知识，再梳理拆解成若干的子问题域。理想的产品架构设计方式是搭积木式的，例如我需要个商城系统就拼一个，需要个推荐系统再拼一个，需要个数据平台就再来拼一个。这就需要我们具有比较广阔的视野吗，电商系统、推荐系统、积分系统、数据系统、反垃圾系统、风控系统、内容管理系统、计费系统、工单系统、开发者系统、账号权限系统等等…….
因此产品架构设计，战略部分来自对业务宏观的理解，将各类能力进行拼装。战术部分需要结合业务对各类子系统进行设计改造以适应现有的业务体系。不同的业务体量对产品方案有不同的需求，做一个小电商和淘宝、京东是不同的，小驴拉大车是拉不动了驴也累死了。即使我们采购了第三方非常完善的方案，团队去运营使用也是有巨大成本的。
高内聚低耦合就是先将板块拆解清楚，每个子模块都可以根据业务的发展情况进行独立迭代扩展而不影响其他模块，这样才是解耦的优秀架构。
4.技术架构设计
产品架构按照业务的天然特性进行功能板块拆解，通常情况下就是符合高内聚低耦合的，因为同一块子业务必然是高内聚的，业务模块互相之间是低耦合的。但到了技术阶段就是理想的状态和残酷的现实。
理想的状态：
残酷的现实：
技术架构的发展从单体架构大泥球到分层架构，再到微服务架构、事件驱动架构、以及“万物皆流”的流计算架构。此处参考阅读覃宇：软件架构编年史(译)。
通过微服务架构可以将原本的单体架构进行拆解，例如账号微服务、订单微服务、工单微服务等。微服务架构有很多拆解设计的思路，此处参考阅读王启军：《持续演进的CloudNative：云原生架构下微服务最佳实践》
对于复杂的中后台业务，通过面向领域的拆解可以与业务子域对应，将业务、产品、技术的设计思路上统一，这样业务引发产品需求变化，也会导致技术大规模的推倒重来。这也是DDD领域驱动设计战略层的精髓。
技术架构设计涉及的基础技术知识建议阅读：李运华：《从零开始学架构》
四、关于领域驱动设计
此处参考阅读：
1.DDD领域驱动设计的核心知识点
2.战略设计
统一语言，做领域驱动设计第一步就是拉齐认知，例如账号、用户到底指的是什么，有什么区别；电商系统的用户和论坛中的用户是不是一个用户等等。这样可以避免后续沟通时产生偏差。
问题空间与解决方案空间：
核心域、支撑域、通用域：
限界上下文与微服务拆解：
关于DDD领域驱动设计的知识不在此处赘述，阅读推荐资料即可。
3.DDD、中台、微服务间关系
五、关于中台体系
阿里的双中台体系为“业务中台+数据中台”，中台的本质是企业能力的复用，实现降本增效。
按照DDD领域驱动设计可以划分出业务的核心域、支撑域、通用域，我们可以先将所有的中台都理解为业务中台，各种可复用的模块被拆解未业务中台中的“XX中心”，例如账号中心、设备中心、数据中心、工单中心等等。其中有些模块因为其通用性，会有商业化的通用解决方案，可以被进一步从内部被拆离至外部。
常见的中台：
六、产品参考清单
行业标准产品参考：
身份中台：
数据中台：
低代码中台：
物联网中台：
视觉中台：
算法中台：
数据分析：
效率工程平台：
VR拍摄：
地球可视化：
七、企业级架构探索
八、避免过度抽象
内容回顾：
本文由@huiter原创发布于人人都是产品经理，未经许可，禁止转载