这里定义了架构的三要素:
职责明确的模块或者组件
组件间明确的关联关系
约束和指导原则
越是简单抽象的定义,越是美,越是通用。小到一个玩具,大到一个国家的运作都可以隐含着这样的内容。
举两个简单的例子,我们来一起看他们的三要素分别是什么。
软件架构
模块:模型、域
关系:一对一、一对多(模型);依赖(域)
原则:单一职责、开闭原则、里氏替换原则等等
组织架构
模块:部门
关系:管理 or 上报
原则:各种管理原则、财务原则
从不同的角度来丰富架构的定义:
架构的原则是简单,但不能有遗漏;
架构的目的是解决问题。问题的尺度上,可以大到国家战略问题、经济问题、民生问题,也可以小到一只钢笔如何均匀地吐墨;时间上,可以是当下的问题,也可以是预期以后会发生的问题;
架构不是一成不变的,它只适合于特定的场景。过去的架构不一定适合现在,当下的架构不一定能预测未来。
架构师是一个角色,定义角色其实是定义职责,架构师的职责是:识别并定义问题,创建、选择或调整架构,从而找到最优的方案,解决问题。
这其实也是架构师做事的一般套路:定义问题->确定架构->提出方案->落地拿结果。这四步中,越是前面的步骤,越是重要,越是抽象,也越是困难,越能体现架构师的功力。
1.什么是问题?
问题的定义很宽泛,生存或是毁灭?这是一个问题。晚上去吃烧烤不?也是一个问题。架构师常说,我的架构解决了什么问题,这里的问题不是一般性的问题,而是特指马克思哲学中的矛盾(矛盾的定义也很宽泛,注意这里是马克思哲学中的矛盾)。
架构师要定义和解决的问题,就是特定领域中的矛盾,解决了矛盾,就得到了发展,取得了收益。
关于问题本质的更多解读,请阅读附录部分荣华老师的原文:如何自顶向下构建架构(进阶之路)。
既然架构师眼中的问题就是马克思哲学中的矛盾,我们就可以从马克思哲学中学习定义问题的系统方法,比如矛盾分主要矛盾、次要矛盾。主要矛盾指:在事物发展过程中处于支配地位,对事物发展起决定作用的矛盾;次要矛盾指:处于从属地位、对事物发展不起决定作用的矛盾;主次矛盾相互依赖、相互影响,并在一定条件下相互转化。
当我们面对复杂的问题时要不断反思,这是不是主要问题?是不是当下最主要的问题?
2.如何区分问题、手段、挑战
我们述职或晋升时常常要说问题、手段、挑战,但这些概念总是混淆在一起,很难区分一件事情是问题还是手段。其实问题、手段、挑战都是一回事,都是矛盾,只是层次不同。比如:
每一个问题可以向下不断展开不断细化,下一级的问题是上一级问题的具体解决手段,当你把“提升性能”当做你Owner的问题时,提升帧率、提高页面秒开率、优化启动耗时就成为了你的具体解决手段;而手段的下一级问题,就是你将面临的挑战,比如你要优化网络耗时,你要面临的挑战就有弱网环境、一些国家区域的带宽问题等等。同理,当你把“提升用户体验”当做你Owner的问题,“提升性能”就变成了你的具体手段,帧率、秒开率、启动耗时就成为了挑战。
3.如何定义问题
思考问题背后的问题,为什么客户需要一匹更快的马?可能客户想要更快的日常交通方式,上升了一个层次后,我们立刻找到了更好的解决方案:造车。
《模型思考者》中对模型的定义是这样的:
模型是对真实世界的抽象,明确定义了各种元素、以及元素之间的关系,可以用来做逻辑推导。
对比架构三要素和模型的定义,相同点是都有元素(组件),以及元素(组件)间的关系。不同的是,架构强调约束和指导原则,用来指导我们如何做事;模型强调逻辑推导能力,指导我们在现有规律下寻找答案或寻求最优解。
参考架构师,用模型思考者的做事方式来给它下定义:面对问题,能看穿客观事物的本质,选取或构建合适的模型,推导出问题的最优解。
就像架构和模型的定义类似,只是突出的重点不同一样,架构师和模型思考者的定义也很类似,重点也不同。架构师的重点是定义问题、解决问题、推动事物发展;模型思考者的重点是看穿事物的本质,遵循规律,找到最优解。
架构师和模型思考者是非常相似的两套做事方法,对于所研究的系统,当我们可以对系统做修改时,可以用架构师思维,定义问题、解决问题,推动系统一步步完善;当我们无法影响系统运行机制时,要用模型思考者思维,洞见其本质,顺势而为,找到最优解。
- END -
如果看到这里,说明你喜欢这篇文章,请 转发 、点赞 。 扫描下方二维码 或者微信搜索「 perfect_iscas 」,添加好友后即可获得 10套程序员全栈课程+1000套PPT和简历模板 , 向我私聊「 进群 」二字即可进入高质量交流群。
↓ 扫描二维码进群↓
喜 欢 文 章 , 点 个 在看