摘要: 架构解决的是人的问题,知道了是解决人的问题,就很容易知道有什么问题要解决。这就需要架构师了,一直觉得架构师是一个技术水平很高的职位,他所做的就是设计系统的功能,设计系统的整体样式。“架构漫谈”提出一个只致力于完成自己的工作,已做好自己的工作为主要目标的人是无法成为一个架构师的。要成为架构师,就要超越 阅读全文
posted @ 2019-06-11 16:39 KNOWNOTING 阅读(75) 评论(0) 推荐(0) 编辑
摘要: 软件的架构设计必须考虑到各方面,根据前期工作确立的领域模型,关键需求,系统约束等进行设计,必须从用户、开发、运维等人员的角度去分析并解决问题。比如说,如果我们的运行架构采用Cluster方式时,就必须小心Cache和Session等的使用;如果我们的业务逻辑要求我们要操作多个数据库时,就要考虑采用支 阅读全文
posted @ 2019-06-11 16:38 KNOWNOTING 阅读(101) 评论(0) 推荐(0) 编辑
摘要: 软件架构的基本设计原则 满足功能性需求和非功能需求:这是一个软件系统最基本的要求,也是架构设计时应该遵循的最基本的原则。 实用性原则:就像每一个软件系统交付给用户使用时必须实用,能解决用户的问题一样,架构设计也必须实用,否则就会“高来高去”或“过度设计”。 接口复用:公共部分可设计成接口,减少冗余, 阅读全文
posted @ 2019-06-11 16:37 KNOWNOTING 阅读(76) 评论(0) 推荐(0) 编辑
摘要: 软件设计的几大原则。有说六的,有说八的,有说十的。我们暂且选最少的,即使是六大原则,真的能遵守好也是难能可贵的。 <1>单一职责原则。 这个原则是相对于“类”而言的,一个“类”的职责越单一,可重用性越好。高内聚,低耦合,精而简。 <2>开放封闭原则。这个原则强调对扩展开放,对修改关闭。这是针对接口和 阅读全文
posted @ 2019-06-11 16:36 KNOWNOTING 阅读(88) 评论(0) 推荐(0) 编辑
摘要: 架构者,骨骼也。架构好,则生命力强,可扩展性强,可维护性高。正所谓根深苗正。 一个应用的底层架构不扎实,不精简,不彻底,那么随着时间的推移,应用的扩展性将变得愈发困难,可读性会越来越差,健壮性也会因此受到影响。 那么,什么样的架构才算是优秀的架构呢?行业里有没有规范呢?答案是肯定的,有。我非常喜欢 阅读全文
posted @ 2019-06-11 16:35 KNOWNOTING 阅读(79) 评论(0) 推荐(0) 编辑
摘要: 就像创造一篇诗词或者写一篇议论文一样,一个软件架构的好坏首先取决于作者是否深刻理解了命题的主旨一样。比如写中秋诗词,主旨是思念亲人、思念故乡还是启发哲思,就能完全得到三组不同的词句“”“”“”,而写作手法却有相似借鉴之处。因此,理解主旨,也就是问题域,是真正区别好架构和劣质架构的根本标准。由此看来, 阅读全文
posted @ 2019-06-11 16:33 KNOWNOTING 阅读(95) 评论(0) 推荐(0) 编辑
摘要: 根据商品的使用价值理论,一个完整的软件产品必须解决某个领域特定的问题。据此,每个软件产品的架构就会呈现出独特的特征和关注点,比如手机终端的APP就会非常关心资源占用、能耗和UED体验等,而一款企业应用则会把快速实现商业逻辑作为首位,不会把能耗作为首要考量因素。即使针对同样的架构维度比如性能,手机AP 阅读全文
posted @ 2019-06-11 16:28 KNOWNOTING 阅读(59) 评论(0) 推荐(0) 编辑
摘要: 架构本身是一个系统化的抽象复杂概念结构,是一个整体。相互制约,比如技术架构的约束可能影响主观判断的变化,如从字段到整表数据冗余场景可以轻易的破坏掉第三范式的设计,性能的要求带入大规模缓存使用让我们不得不放弃完美的一致性追求,广为人知的CAP定理只能提供三选二的选择等等。在以上架构任务之上,架构师更应 阅读全文
posted @ 2019-06-11 16:27 KNOWNOTING 阅读(78) 评论(0) 推荐(0) 编辑
摘要: 客观选择是架构师(团队)根据对现有技术的把控和理解,选择一系列技术栈来实现主观判断产生出来的软件要素,诸如采用Spring Cloud来构建应用,选择MySQL作为数据库平台,选择AWS抑或阿里云作为部署平台等等,也就是通常所说的技术架构。这一部分还包括一些特殊的看似主观的判断,主要指一系列设计模式 阅读全文
posted @ 2019-06-11 16:26 KNOWNOTING 阅读(86) 评论(0) 推荐(0) 编辑
摘要: 从架构师决定软件架构的角度来看,可以分为主观判断、客观选择两部分。主观判断包括了架构师(以及团队)对问题域理解,以及由此产生的软件设计要素,诸如架构分层、模块划分、API设计、数据模型设计,也就是通常所说的应用架构、信息架构和开放架构;甚至架构方法的选择,如是否采用DDD来建模,交流、描述整个软件的 阅读全文
posted @ 2019-06-11 16:25 KNOWNOTING 阅读(79) 评论(0) 推荐(0) 编辑
摘要: 程序员的迷茫因为长期埋没于软件世界的浩大的分工体系中,无法看清从业务到软件架构的价值链条,无法清楚定位自己在分工体系的位置,处理不好自身与技术、业务的关系所致,所以在这里我想谈谈分工。架构师为了使软件系统更好的服务业务,必然将软件系统生命周期进行拆分,比如分出开发生命周期、测试生命周期、用户访问生命 阅读全文
posted @ 2019-06-11 16:22 KNOWNOTING 阅读(118) 评论(0) 推荐(0) 编辑
摘要: 互联网公司正是借助大规模的软件系统承载着繁多的业务功能,使其拥有巨大的服务能力并借助互联网技术突破了空间限制,高效低廉解决了业务问题,创造了丰厚的利润,这是人肉所不可比拟的。 理解了这一层面的概念,你就可以清楚这个价值链条即:公司依靠软件系统提供业务服务而创造价值,程序员则是通过构建并持续演进软件系 阅读全文
posted @ 2019-06-11 16:20 KNOWNOTING 阅读(83) 评论(0) 推荐(0) 编辑
摘要: 业务、技术与软件系统的价值链 那么什么是业务呢?就是指某种有目的的工作或工作项目,业务的目的就是解决人类社会与吃喝住行息息相关的领域问题,包括物质的需求和精神的需求。使开展业务活动的主体和受众都能得到利益。通俗的讲业务就是用户的痛点,是业务提供方(比如公司)的盈利点。而技术则是解决问题的工具和手段。 阅读全文
posted @ 2019-06-11 16:17 KNOWNOTING 阅读(80) 评论(0) 推荐(0) 编辑
摘要: 在浩大的软件世界里,作为一名普通程序员,显得十分渺小,甚至会感到迷茫。我们内心崇拜技术,却也对日新月异的技术抱有深深的恐惧。技术市场就像这喜怒不定的老天爷,今天下个大数据雨,明天挂个人工智能风,面对琳琅满目的技术浪潮的冲击,程序员难免深感无力,深怕错过了技术潮流从而失去了职场竞争力。有时候我会思考难 阅读全文
posted @ 2019-06-11 16:16 KNOWNOTING 阅读(89) 评论(0) 推荐(0) 编辑