关键内容：架构特点、业务架构、领域架构、分层架构 作者：小步 全文约5475字 阅读大约15分钟 提示：以下内容仅为个人分享，有兴趣交流的伙伴可在下方讨论区留言。
知识库首页
提示：上方链接属于全手册首页，伙伴们打开后可以关注或收藏，用于日常工作查看，其中关注后，可以实时收到文档更新通知，希望对你有所帮助。
😅当前文档处于创作中，内容随时出现变更，会存在FLASH记录的草稿，所以，慎看。。。。
前言
说产品架构，就必须要从架构说起，记得在做产品工作第一年时，当时还没有比较清晰的架构认知，在做产品设计时，视野往往只会聚焦在某个场景应该增加什么功能，便开始设计，很少去考虑这个功能在整个产品中所处的位置以及在业务中所处的节点。
但随着需求的不断膨胀，产品形态开始陆续变得臃肿，系统从最开始的有序变得逐渐无序，用户开始无法理解。
同时作为产品设计者有可能也陷入到了无法进行良好的产品扩展和维护的状态当中，业务也足够的复杂，冗长，此时可能会开始聚合一些原本应该放在一起的业务点，产品亟待重新构建，因此架构思维便在此刻开始展现。
打破认知，了解架构的世界观
架构这个名词术语，进入个人视野是来源于求学生涯中对计算机语言C语言、数据结构的学习，以及工作以后，陆续出于解惑自学了Java语言的J2EE框架，Mysql数据库、Linux系统、以及关于网络安全相关等技术知识。
得益于这部分知识的不断丰富叠加，开始了从模糊到逐步清晰的过程，一定程度的了解了互联网产品完整的前端展现、后端数据之间的关系，也开始认识到架构的艺术。
因此要尝试更好的理解架构思考，丰富自己的知识积累是少不了的环节，也是给大家分享的核心点。
架构，就是从无序到有序的过程
那么什么是架构呢？这个我的理解是它并没有标准定义，因人而异，因为它只是个体抽象思维的表达方式而已，因此以下内容为个人认知仅供参考。
一句话定义：架构，是一个将信息高效有序重组的过程手段。
即为了完成某个需求目标，采用不同维度的分解，构建不同维度之间有序的信息流，通过完成信息从无序到有序的转变，最终实现信息的高效重组。
认知建立，站在巨人肩上俯瞰
为了有更深度的认知，我给大家分享两个对我影响最深的来自于技术测的架构认知。
第一个：典型“应用层、服务层、数据层”的架构，也是个人整体架构思维的起点，你后期会发现这样的架构体系，影响到了互联网产品的方方面面
图片来源《大型网站技术架构》
如图所示，本架构图属于架构类别中的技术架构，抽象维度是按各个模块分工进行架构，每一层有明确的分工，它是常规架构图的表现形态，简单介绍如下：
其中：前端架构、应用层架构、服务层架构、存储层架构、后台架构属于常规业务架构，是每一个互联网产品必不可少的内容，而数据中心机房架构，主要指物理设备的架设关系，分配的地址等。安全架构是目前互联网发展状态中必不可少的环节，这都源于数据安全的需求，因此除了常规的业务侧架构，还会有数据采集与监控。这里我仅做引入，不做详解，因为技术架构是根据需求走的，具体业务再具体分析。
当然为了让大家有更深刻的认知，我也给大家推荐一本我几年前，在自学技术项内容时，看到的书籍，它能让你了解一下技术测的架构的前世今生，进而理解作为产品侧的架构认知，它是讲大型网站架构的知识，选择它的点很简单，当下的随着数据服务组建庞大，它里面涉及到的架设内容，将会覆盖到互联网/AIoT等多个领域，因此里面说的几层架构，都是有很强的指导意义。
第二个，开发设计模式中的MVC模式。它的魅力是架构业务实际运转时候的机制和状态，它的颗粒度更细，但依旧有分工的身影。
如上图所示，它主要用在开发时候的分层设计，不管前后台开发，都有类似的机制。
简单介绍如下:
- 显示层View：主要负责显示数据（Html、Css、jQuery等等）
- 控制层Controller：主要功能是处理用户的请求
- 模型层Model：主要功能是与数据库交互，它又分为Service和Dao层，
- Service层：负责一些业务处理，比如说：获取数据库连接，关闭数据库连接，事务回滚或者一些复杂的逻辑业务处理
- Dao层：(Database Accept Object) 负责访问数据库，对数据的操作，获取结果集，将结果集中的数据装到OV（Object Value）对象中，之后再返回给Service层
由于这部分涉及较多开发项内容，因此如果看不懂的伙伴，仅做了解即可，对技术开发有兴趣可以深度了解，我不延展。
小结
通过以上内容，相信大家对架构有一定的感性认识，总的来说，我认为架构的作用是让内外部世界更有序，更高效，更长久稳固，同时它为工作提供了一定的方向性，这是我感知到的最大的美。
在完成认知以后，我便是海量学习新的知识，虽然不做技术，但只要涉及到产品链路上的所有内容，都将对架构产生积极作用，也因此，后面随着产品工作经验的不断丰富，开始陆续认知到架构的魅力可以延伸到各个领域，也就有了现如今对产品工作维度的架构认识。
正文
本文便是基于从技术架构认知过渡到产品工作上的架构认知，聚焦分享笔者对产品架构方面的思考和总结，思路基本如下：介绍互联网全貌世界观、产品架构之间的关系、产品架构有什么特点，以及有哪些我目前的架构方法，最后应用案例的分享。
俯瞰世界观，互联网的世界
都说“身在山中，不知山大”，因此，我尝试往上飞了一下，结合个人目前的认知体系构建了下面一套完整性的场景框架，以此作为后续架构场景的说明素材。
接下来，我将介绍我的分层依据，尽可能的打破大家对目前互联网圈各种术语的认知模糊点，同时增加跨部门跨领域沟通的思路，当然范围也是有限的。
前端和后端的边界——可见与不可见
前端：对普通人可见，对开发者也可见的内容。如手机应用app、浏览器看到的网站、PPT、以及浏览器本身也是个前端。
后端：对开发者可见，对普通人不可见的内容。如数据库、应用服务、安全连接等，它主要完成的就是背后业务的实际流转和处理。
核心处理内容边界——理解产品形态
从客户能够感知到实际落地的流程中，分为表现层、业务层、部署层。
表现层：就是互联网产品的不同形态，也是产品工作者核心接触到的类目。
（1）按照主流应用操作系统划分展现的产品形态（其他OS类比）
手机或智能终端类分为Andriod和ios的app应用，如抖音、微信等等
电脑类类分为Window和MacOS的PC软件，如QQ、邮箱软件、浏览器等等
（2）按照基于应用上做技术迭代产生的新产品形态
基于应用生态自身的小程序，主要在微信、支付宝、百度等头部公司推广应用中
基于web浏览器上的web站点，常见的产品形态就是网站、SaaS等
业务层：这里主要根据不同领域的业务实际情况，衍生出来的不同产品分类
我将它分为后台服务类和数据库服务的东西。
后台系统服务，主要跟实际业务有关系，由各种业务类型驱动的服务组合，所以什么类别的产品是以业务而定，它的表现形态，可以为各种形态。举个例，我们的常用的微信，最初就是通讯业务，后面微信公众号诞生，便成了内容服务商，对通讯录的管理、对微信创作者的管理，就是CRM。以此类推比如OA/ERP/WMS等等。
数据库服务，主要为提供一整套数据存储的机制的工具集合，应用层的开发，主要是调用整套工具，主要分为关系型：Mysql/Oracle、非关系型：Redis/MongoDB….。
部署层：这里其实就是我们普通从业者很少接触的内容，物理部署的分类
理解这层，就需要给大家普及一个概念，就是客户端和服务端的概念。
客户端主要指发起服务申请的一端，服务端则是指提供实际业务服务的一端。实际部署中，若客户端和服务端同时部署在一个载体上，比如我们的手机通讯录，它本地就具备的业务能力，就是主流的
我们口中的应用app以及后台服务，实际上分别部署在不同的载体，有一类是我们常见的app，若不联网则本地系统就充当了所有服务
推荐阅读：🔥互联网领域产品术语层级关系（总结）这里面的内容也可能帮你进一步理解架构视角
架构的分类
业务是起点，技术是路径，产品是形式
架构，个人根据领域属性，总体分为三大类：产品架构、业务架构、技术架构。每一层往下都可以根据不同抽象维度进行细分。
他们的关系如图所示：
即存在业务需求后，会产生某类产品形态去满足业务需求，而为了实现产品，便需要有实现路径上的技术支持。因此，这里需要达到的第一个共识：架构源于需求。产品架构强调的是表现形式，业务架构强调的是需求起点，技术架构强调的实现的路径。
业务架构
即抛开产品形态，围绕客户实际的业务场景进行构建，类似于人货场，你需要明确的是人货场三者的业务关系，基于此之上构建产品
产品架构
即根据业务架构中需要解决的需求场景，进行产品化的构建，里面抽象粒度涉及到的产品或功能模块，由具体场景决定
技术架构
即根据产品架构中描述的业务功能场景，进行领域模型的技术方案架构，此部分示例图略，产品侧需要了解到的是数据表结构的关系，以及领域模型等
架构的特点
那么，产品架构有什么特点呢？
对此个人有几个典型特点的认知：边界性、相关性、层次性、可扩展性。
为了方便大家的理解几个特点的来源，我将用个人AIoT产品方面架构的一部分内容，以此作为说明
需要强调的是，架构一定是来源于实际业务需求的解构和重组，不是凭空捏造，每个模块存在有它应具备的功能。
边界性
边界性是指每个模块有各自的个体分类，它们具有在当前抽象维度下的边界，如产品中心，则需求的迭加应该是表达涉及产品的全部内容，凡是与产品无关的内容，便不能架构在此类目中
相关性
相关性是指模块与模块之间的连续，它们的关系是什么，谁负责什么内容，谁是核心中枢，业务关联是如何流转。
层次性
层次性是指模块与元素之间的层次状态，可以类比于父子关系的概念，如开发者中心为父，开发者管理即为子，而这里一般是根据抽象的颗粒度大小决定你的最小单元表达的内容。如这里的最小的单元就是一个功能单元。
可扩展性
可扩展性是指模块架设时，需考虑各模块元素之间，后续业务发展可能带来的变化，一般要考虑近3年内可能的变化，如果是从0到1构建初期的产品，当下很多公司的架构其实已经足够前期使用，所以可以站在巨人的肩膀上起飞，除非你的业务架构有明显的独特性。就比如“双十一”背后的并发处理能力，普通规模的产品扩展性大概率不会超越这一类的事件，所以完全可以再此基础上进行做减法的处理，仅做引用。
小结
OK，以上介绍的目的是给大家定义一个大的架构框架，当然实际在架构执行时，内容还会不断丰富，在我认知里，架构的魅力在于，当你深刻理解实际需求场景，做到最小粒度的抽象，并将其流转落地，后面的产品发展中，该产品是否能够更长久的发展下去，便是一个高质量架构的判断标准，同时也间接表达了作为产品设计者的业务能力，当然实际工作落地当中，会受到不同因素影响，导致落地结果与初衷相悖，但这依旧无法抵挡它的魅力。
分类介绍
什么是产品架构
产品架构就是以解决业务场景需求而构建的产品功能模块间的关系总和
产品架构的方法
架构分类的标准，其实取决于，作为设计的核心架构思想或者说方法，个体存在着不同的差异，因此以下的架构内容的方法是笔者个人抽象标准定义，可能会跟大家认知有一定的差异，仅供参考。
架构是创造产品时的结构性思考提炼，是业务梳理后的重组思考。
基于知识梳理纵横维度的思路，我总结了三种架构方法：业务架构、分层架构、领域架构，他们的关系如下
首先，其底层核心思想是以边界性的原则完成结构搭建，然后再用由粗到细的方式进行内容丰富，这里其实就是典型的金字塔原理展示，也是我们常规的思维搭建方法，所以并没有太特别的地方。
实际工作中，主要发生的场景不外乎两种：
1 产品0到1
在做产品设计前，我们常常会进行需求整理，进行功能抽象，并不断提炼，最终形成完整的框架内容，0-1最大的特点就是不确定性且变化快，因此灵活性是最高优先级，这个时候的产出的结果大概率一定不会是最终的架构形态，但作为设计者，要做的是，尽量让目标内容往最终理想的架构模型靠近，这里除了架构能力，剩下的就是对团队集体执行力的要求。
2 产品重构
在产品经过一定时间的沉淀，早期的架构很大程度无法继续支撑后续的业务，因此便会进行二次提炼和整合，得到2.0的产品框架，对应的产品业态的认知也会发生巨大的变化，一旦重构对公司来说，其实就相当于一次换血且风险较高，因此，重构应该是一个公司级的战略决策，需要大力资源支撑，且重构的试错成本将远高于0-1时期，但从客观来说，重构其实也是另外一次0-1的变化，这个时候的产品设计者，个人建议还是回到0-1的心态，重新认识重构后的产品。
由此可见，架构的出发点始终是来源于实际需求，需求是架构所必需的关键要素。基于此我的建议是当你有架构思维时，可以将每一件小业务模块尝试作为架构点去思考，尽量将视角切换为俯瞰视角，这样做的好处是，你在前期可以从逻辑上便可做评估，业务之间的关系是否合理，后期可能会面临怎样的问题。
业务架构
业务架构的基础是对业务需求的理解，需要通过点线面的方法聚焦到某一条垂直模块业务的架构设计，如营销模块，需要梳理，你的营销思路，思路的结果其实就是业务架构逻辑。
在新零售或者电商领域，基本上可以总结为人货场三者之间的关系，即
人代表用户、货代表匹配的产品、场代表展示产品的地方
所有产品设计都需要考虑这三者之间在产品中的位置
此处笔者的思路和操作手段就是对业务做全流程的梳理，梳理时有个最核心的元素即，每个场景都需要包含角色、动作、流程，即脑袋里需要有相对完善的用例说明
比如梳理人的时候，重点梳理即当前产品系统的角色有哪些
梳理货的时候，重点梳理货的来源、去向、中间的过程，这里就会演变出物流流程
梳理场的时候，重点梳理场即渠道，在哪些渠道展示和曝光
业务架构的思路方法，其实适用于大部分情况，只要逻辑和认知能够跟上，大部分的业务逻辑架构都能完成
领域架构
领域架构的核心是跳出业务本身，让产品人聚焦到产品即将面临的生态竞争状态，一般做领域架构的时候更多是为了分析市场竞争形式，特别是做平台产品设计时，避免不了从供需视角进行领域扩展到生产者&消费者视角，而这就是平台需要思考的内容，即如何让生产者更好的生产，消费者能更好的消费
基于此，用户-终端-系统-环境生态，即聚焦到某个行业领域的架构设计，有哪些基本元素、相互关系是什么，策略是什么，便构成了领域架构的设计思路
分层架构
应用层-服务层-数据层，即聚焦底层支撑的架构设计，这部分依赖于技术的架构，一切是服务于应用层的应用。
架构背后的社会关系
其实在整理架构这个垂直方法的时候，我认识到架构另一层的含义，即除了表达产品或业务模块线间的关系以外，它其实也是社会分工下的映射，你可以看到每个结构分层以后，如果业态足够大，每个部分都将衍生出一个职业分工。
未完待续~~~~
相关说明
若有收获，就点个赞吧
0 人点赞
