架构漫谈(四):如何做好架构之架构切分

本文探讨了架构切分的本质,即对利益相关者的利益进行调整。通过合理的切分,可以使每个参与者的权利与义务相匹配,从而提高整体效率。文章还详细阐述了切分的原则及其对组织架构的影响。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前一篇已经讲了如何识别问题。在识别出是谁的问题之后,会发现,在大部分情况下,问题都迎刃而解,不需要做额外的动作。很多时候问题的产生都是因为沟通的误解,或者主观上有很多不必要的利益诉求导致的。但是总还有一部分确实是有问题的,需要做调整,那么就必须要有所动作,做相应的调整。这个调整就是架构的切分。

  切分就是利益的调整

  我们要非常的清楚,所有的切分调整,都是对相关人的利益的调整。为什么这么说呢,因为维护自己的利益,是每个人的本性,是在骨子里面的,我们不能逃避这一点。我们以第一篇文章里面的例子为例来做解释。

  我们已经知道,随着社会的发展,分工是必然的,为什么呢? 这个背后的动力就是每个人自己的利益。每个人都希望能够把自己的利益最大化,比如:生活的更舒适,更轻松,更安全,占用并享有更多的东西。但是每个人的能力和时间都非常的有限,不可能什么都懂,所以自然需要舍掉一些自己不擅长的东西,用自己擅长的东西去换取别人擅长的东西。

  对比一个人干所有的事情,结果就是大家都能够得到更多,当然也产生了一个互相依赖的社会,互相谁都离不开谁。这就是自然而然而产生的架构切分,背后的原动力就是人们对自己利益的渴望。人们对自己利益的渴望也是推动社会物质发展的原动力。

  在这个模式下,比较有意思的是,每个人必须要舍掉自己的东西,才能够得到更多的东西。有些人不愿意和别人进行交换,不想去依赖于别人,这些人的生活就很明显的差很多,也辛苦很多,自然而然的就被社会淘汰了。如果需要在这个社会上立足,判断标准就变成了:如何给这个社会提供更好更有质量的服务。提供的更好更多的服务,自然就能够换取更多更好的生活必需品。实际上这就是我们做人的道理。

  为什么需要切分?

  当人们认识到要主动的去切分一个系统的时候,毫无疑问,我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点,这是大方向。结合前一篇“识别问题”,一旦确定了问题的主体,那么系统的利益相关人(用现代管理学语言叫:stakeholder)就确定了下来。所发现的问题,会有几种情况:

  1. 某个或者某些利益相关人负载太重。
  2. 时间上的负载太重。
  3. 空间上的负载太重,本质上还是时间上的负载太重。
  4. 某个或者某些利益相关人的权利和义务不对等。

  切分的原则

  情况1是切分的原因,情况2是切分不合理而导致的新的问题,最终还是要回到情况1。对于情况1,本质上都是时间上的负载。因为每个人的时间是有限的,怎么在有限的时间内做出更多的事情?那么只有把时间上连续的动作,切分成时间上可以并行的动作,在空间上横向扩展。所以切分就要有几个原则:

  1. 必须在连续时间内发生的一个活动,不能切分。比如孕妇怀孕,必须要10月怀胎,不能够切成10个人一个月完成。

  2. 切分出来的部分的负责人,对这个部分的权利和义务必须是对等的。比方说妈妈10月怀胎,妈妈有权利处置小孩的出生和抚养,同样也对小孩的出生和抚养负责。为什么必须是这样呢? 因为如果权利和义务是不对等的话,会伤害每个个体的利益,分出来执行的效率会比没有分出来还要低,实际上也损害了整体的利益,这违背了提升整体利益的初衷。

  3. 切分出来的部分,不应该超出一个自然人的负载。当然对于每个人的能力不同,负载能力也不一样,需要不断的根据实际情况调整,这实际上就是运营。

  4. 切分是内部活动,内部无任怎么切,对整个系统的外部应该是透明的。如果因为切分导致整个系统解决的问题发生了变化,那么这个变化不属于架构的活动。当然很多时候当我们把问题分析的比较清楚的时候,整个系统的边界会进一步的完善,这就会形成螺旋式的进化。但这不属于架构所应该解决的问题。进化的发生,也会导致新的架构的切分。

  原则2是确保我们不能违反人性,因为维护自己的利益,是每个人的本性。只有权利和义务对等才能做到这一点。从原则2的也可以推理,所有的架构分拆,都应该是形成树状的结果,不应该变成有向图,更不应该是无向图。很多人一谈架构,必谈分层,但是基本上都没意识到,是因为把一个整体分拆为了一棵树,因为有了树,才有层。

  从某种意义上来说,谈架构就是谈分层,似乎也没有错,但是还是知道为什么比较好。从根节点下来,深度相同的是同一层。这个是数学概念,我就不展开了,感兴趣可以去复习一下数学。

  同样我们看一个组织架构,也可以做一个粗略的判断,如果一个企业的组织架构出现了“图”,比方说多线汇报,一定是对stakeholder的利益分析出现了问题,这就会导致问题2的发生。问题2一旦出现,我们必须马上要意识到,如果这个问题持续时间长,会极大的降低企业的运作效率,对相关stakeholder的利益都是非常不利的,同样对于企业的利益也是不利的。必须快速调整相关stakeholder的职责,使得企业的组织架构成为一个完美的树状,并且使得树的层数达到尽可能的低。只有平衡树可以比较好的达到这个效果。

  当然如果某个节点的能力很强,也可以达到减小树的高度的结果。技术的提升,也是可以提升每个节点的能力,降低树的层数。很多管理学都在讨论如何降低组织架构的层数,使得管理能够扁平化,原因就在于此,这里就不展开讨论了。从这里也基本可以得出一个结论,一个好的组织的领导,一定也是一个很好的架构师。

  切分与建模

  实际上切分的过程就是建模的过程,每次对大问题的切分都会生成很多小问题,每个小问题就形成了不同的概念。这也是系列第二篇文章尝试表达的。这些不同的概念大部分时候人们自发的已经建好了,架构师更多的是要去理解这些概念,识别概念背后所代表的的人的利益。比如人类社会按照家庭进行延续,形成了家族,由于共享一片土地资源,慢慢形成了村庄,村庄联合体,不同地域结合,形成了国家。由于利益分配的原因,形成了政权。每次政权的更迭,都是利益重新分配的动力所决定的。

  同样对于一个企业也是一样的,一开始一个人干所有的事情。当业务量逐渐变大,就超过了一个人能够处理的容量,这些内容就会被分解出来,开始招聘人进来,把他们组合在一起,帮助处理企业的事务。整个企业的事务,就按照原则2,分出来了很多新的概念:营销,售前,售中,售后,财务,HR等等。企业的创始人的工作就变成了如何组合这些不同的概念完成企业的工作。如果业务再继续增大,这些分出来的部分还要继续分拆,仍然要按照原则2才能够让各方达到利益最大化。如果某个技术的提升,提高了某个角色的生产力,使得某个角色可以同时在承担更多的工作,就会导致职责的合并,降低树的层数。

  切分的输出和组织架构

  架构切分的输出实际上就是一个系统的模型,对于一个整体问题,有多少的相关方,每个相关方需要承担哪些权利和义务,不同的相关方是如何结合起来完成系统的整体任务的。有的时候是从上往下切(企业),有的时候是从下往上合并,有的时候两者皆有之(人类社会的发展)。而切分的结果最终都会体现在组织架构上,因为我们切分的实际上就是人的利益。

  从这方面也可以看出,任何架构调整都会涉及到组织架构,千万不可轻视。同样,如果对于stakeholder的利益分析不够透彻,也会导致架构无法落地,因为没有人愿意去损坏自己的利益。一旦强制去执行,人心就开始溃散。这个也不一定是坏事,只要满足原则2就能够很好的建立一个新的次序和新的利益关系,保持组织的良性发展,长久来看是对所有人的利益都有益的,虽然短期内有对某些既得利益者会有损害。

  总结一下

  1. 架构的切分的导火索是人的负载太重。
  2. 架构的切分实际就是对stakeholder的利益进行切分或合并,使得每个stakeholder的权责是对等的,每个stakeholder可以为自己的利益负责。
  3. 架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进。
  4. 架构切分的结果一定是一个树状,这也是为什么会产生分层。层数越多沟通越多,效率越低,分层要越少越好。尽可能变成一颗平衡树,才能让整个系统的效率最大化。
标题基于SpringBoot+Vue的社区便民服务平台研究AI更换标题第1章引言介绍社区便民服务平台的研究背景、意义,以及基于SpringBoot+Vue技术的研究现状和创新点。1.1研究背景与意义分析社区便民服务的重要性,以及SpringBoot+Vue技术在平台建设中的优势。1.2国内外研究现状概述国内外在社区便民服务平台方面的发展现状。1.3研究方法与创新点阐述本文采用的研究方法和在SpringBoot+Vue技术应用上的创新之处。第2章相关理论介绍SpringBoot和Vue的相关理论基础,以及它们在社区便民服务平台中的应用。2.1SpringBoot技术概述解释SpringBoot的基本概念、特点及其在便民服务平台中的应用价值。2.2Vue技术概述阐述Vue的核心思想、技术特性及其在前端界面开发中的优势。2.3SpringBoot与Vue的整合应用探讨SpringBoot与Vue如何有效整合,以提升社区便民服务平台的性能。第3章平台需求分析与设计分析社区便民服务平台的需求,并基于SpringBoot+Vue技术进行平台设计。3.1需求分析明确平台需满足的功能需求和性能需求。3.2架构设计设计平台的整体架构,包括前后端分离、模块化设计等思想。3.3数据库设计根据平台需求设计合理的数据库结构,包括数据表、字段等。第4章平台实现与关键技术详细阐述基于SpringBoot+Vue的社区便民服务平台的实现过程及关键技术。4.1后端服务实现使用SpringBoot实现后端服务,包括用户管理、服务管理等核心功能。4.2前端界面实现采用Vue技术实现前端界面,提供友好的用户交互体验。4.3前后端交互技术探讨前后端数据交互的方式,如RESTful API、WebSocket等。第5章平台测试与优化对实现的社区便民服务平台进行全面测试,并针对问题进行优化。5.1测试环境与工具介绍测试
资源下载链接为: https://pan.quark.cn/s/9648a1f24758 Java中将Word文档转换为PDF是一种常见的技术需求,尤其在跨平台共享、保持格式一致性和便于在线预览等场景中非常实用。通常,开发者会借助专门的库来实现这一功能,其中Aspose.Words是一个非常强大的选择。Aspose.Words是由Aspose公司开发的文档处理组件,支持多种文件格式,包括Word和PDF。它提供了丰富的API,方便开发者在Java应用程序中进行文件转换、编辑和格式化操作,尤其在Word转PDF方面表现卓越。 使用Aspose.Words进行Word转PDF的步骤如下: 添加依赖:通过Maven或Gradle等工具将Aspose.Words的Java库引入项目。 加载Word文档:使用Document类加载Word文件,例如: 配置输出选项:创建PdfSaveOptions对象,用于设置PDF保存时的选项,如图像质量、安全性等。 执行转换:调用Document的save方法,传入输出路径和PdfSaveOptions对象,例如: 支持多种输出格式:Aspose.Words不仅支持将Word转换为PDF,还能转换为HTML、EPUB、XPS等多种格式,只需更换SaveOptions的子类即可。 保持格式与样式:在转换过程中,Aspose.Words能够最大程度地保留源文档的格式和样式,包括文本样式、图像位置、表格布局等。 优化性能:Aspose.Words支持并行处理和多线程技术,可以显著提高大量文档转换的速度。 处理复杂文档:它能够处理包含宏、复杂公式、图表、脚注等元素的Word文档,确保转换后的PDF内容完整且可读。 安全性与版权:在转换过程中,可以设置PDF的访问权限,例如禁止打印或复制文本,从而保护文档内容。 在实际开发中,还需要注意错误和异常的处理,以
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值