架构师

CSDN看到一篇介绍架构设计的博客，内容提纲挈领，内容丰富。依据原文整理，加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接： https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？ 想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君： 区分系统、模块、组件、框架和架构 系统(system)和子系统：有 关联 的个体，根据某种 规则 运行，共同完成独特的 功能 。子系统：系统的组成部分。 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。 框架

3 月，跳不动了？>>> CSDN看到一篇介绍架构设计的博客，内容提纲挈领，内容丰富。依据原文整理，加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接： https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。 Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？ 想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君： 区分系统、模块、组件、框架和架构 系统(system)和子系统：有 关联 的个体，根据某种 规则 运行，共同完成独特的 功能 。子系统：系统的组成部分。 模块(module)和组件(component)：模块和组件都是系统的组成部分，只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块，从物理角度拆分得到的是组件。 模块是为了实现职责分离， 组件是为了实现复用。 框架

现在的软件系统越来越复杂，当然相应地，架构的作用也越来越明显。作为开发人员，我们每天都在和架构打交道，在这个过程中，对于架构也经常会产生各种各样的问题： 什么是架构？架构都有哪些分类，分别解决什么问题呢？ 怎样才是一个好的架构设计？我怎么才能成长为一名优秀的架构师呢？ 这些问题涉及我们对架构的认识，也是学习和运用架构的开始。所以，今天，我们就来深入地分析架构的实质，让你能够透彻地理解它。 架构的本质 物理学中有个很著名的“熵增定律”：一个封闭系统，都是从有序到无序，也就是它的熵（即混乱程度）会不断地增加，最终系统会彻底变得无序。 这个理论放在软件系统的演化上，也是非常适用的。 一方面，随着业务需求的增加，我们会往系统里不停地添加业务功能；另一方面，随着访问量的不断增加，我们会不断通过技术手段来加强系统非业务功能。如果事先不做良好的设计，随着时间的推进，整个系统野蛮生长，就会逐渐碎片化，越来越无序，最终被推倒重来。 不过，自然界中的生物可以通过和外界交互，主动进行新陈代谢，制造“负熵”，也就是降低混乱程度，来保证自身的有序性，继续生存。比如，植物通过光合作用，把光能、二氧化碳和水合成有机物，以此滋养自己，延续生命。对于软件系统，我们也可以主动地调整系统各个部分的关系，保证系统整体的有序性，来更好地适应不断增长的业务和技术变化。这种系统内部关系的调整就是通过架构实现的，所以

文 / 周爱民（《程序员》2008年4月刊）来自CSDN 引子 究竟是什么让你在同一个位置上——例如程序员或技术负责人——工作了三年、五年或者更久，而仍然得不到任何的发展空间？你觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨的薪水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对昨天升职的那个同事不满……你开始计划明天就要跑单，或者准备考虑提出加薪却又心怀忐忑。 如果技术人员有发展的轨迹，那么他要么“看透工具的本质，把关注点转移到‘团队’的圈子里去”，要么“顺着代码铺就的道路，亦步亦趋地成为良匠大师”。仅以技术方向而言，你大概可以做到架构师、总架构师甚至首席架构师；但问题是：你现在还只是一个程序员。那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师的能力模型。 你能不能做一个好的架构师？ 架构师不是界定一个技术高下的职位名称，而是一个职务。所谓职务，包括职——职位，务——工作。前者决定了你具备哪些资源，可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完成的工作列表。 所以我说“架构师”不是指“一个能做架构的人”。前者是把架构师当职能，后者是当工人。能做一份工作列表中的事，并不等于就成为相应职位上的人。在管理体系里面，你的个人特性决定了你在哪个位置，而技术技能只是做事实施的必需

要想从一名普通程序员发展成为优秀的架构师，“个人特性”与“技术技能”缺一不可；而“技术专业能力”、“人际关系能力”和“业务能力”更是优秀架构师重要的三种能力。 引子 究竟是什么让你在同一个位置上——例如程序员或技术负责人——工作了三年、五年或者更久，而仍然得不到任何的发展空间？你觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨的薪水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对昨天升职的那个同事不满……你开始计划明天就要跑单，或者准备考虑提出加薪却又心怀忐忑。 如果技术人员有发展的轨迹，那么他要么“看透工具的本质，把关注点转移到‘团队’的圈子里去”，要么“顺着代码铺就的道路，亦步亦趋地成为良匠大师”。仅以技术方向而言，你大概可以做到架构师、总架构师甚至首席架构师；但问题是：你现在还只是一个程序员。那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师的能力模型。 你能不能做一个好的架构师？ 架构师不是界定一个技术高下的职位名称，而是一个职务。所谓职务，包括职——职位，务——工作。前者决定了你具备哪些资源，可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完成的工作列表。 所以我说“架构师”不是指“一个能做架构的人”。前者是把架构师当职能，后者是当工人。能做一份工作列表中的事

不论是在公司内部，还是在面试过程中，经常看到很多开发人员，说想成长为架构师，但是实际上却像一支无头苍蝇一样学习、成长。所以今天我就来简单总结一下，开发人员要成长为一个架构师，都应该学习哪一方面的知识。也就是：架构师的能力模型。 （PS：本文纯属个人见解，并不一定完全正确。对于此类话题，每个人可能都有不同的看法。欢迎大家拍砖。） 开发人员职业发展方向 在说明架构师能力模型前，我得先说明开发人员在职场中的职业发展方向图。 开发者应该根据自己的性格、爱好来选择自己的职业方向。对于性格外向、愿意多与人交流、沟通能力较好的同学，可以考虑向管理方向发展。对于热爱技术、喜欢钻研、性格偏内向的同学，则更适合往技术方向发展。 两个方向并没有好坏之分，只是术业有专攻而已。两个方向也不是完全独立的，对于技术总监、架构师及其以上的岗位，往往也需要较强的沟通能力，以及一定的管理能力。 CTO 是很多开发人员理想中的最终职业方向。但是对于不同的公司而言，对 CTO 要求不尽不同（可以看看 2016年炒得比较火的某 CTO 离职事件）。所以 CTO 也会由不同的岗位成长而来。但是，并不意味着每个人都要以 CTO 为自己的职业目标。 图中黑体的岗位，都可以作为开发人员的职业方向。 对于还没有职业方向的的开发人员来说，选择好一个奋斗的方向， 非常关键。方向对了，就不怕路远！ 方向不清晰，则会做很多徒劳无功的事

不论是在公司内部，还是在面试过程中，经常看到很多开发人员，说想成长为架构师，但是实际上却像一支无头苍蝇一样学习、成长。所以今天我就来简单总结一下，开发人员要成长为一个架构师，都应该学习哪一方面的知识。也就是：架构师的能力模型。 （PS：本文纯属个人见解，并不一定完全正确。对于此类话题，每个人可能都有不同的看法。欢迎大家拍砖。） 开发人员职业发展方向 在说明架构师能力模型前，我得先说明开发人员在职场中的职业发展方向图。 开发者应该根据自己的性格、爱好来选择自己的职业方向。对于性格外向、愿意多与人交流、沟通能力较好的同学，可以考虑向管理方向发展。对于热爱技术、喜欢钻研、性格偏内向的同学，则更适合往技术方向发展。 两个方向并没有好坏之分，只是术业有专攻而已。两个方向也不是完全独立的，对于技术总监、架构师及其以上的岗位，往往也需要较强的沟通能力，以及一定的管理能力。 CTO 是很多开发人员理想中的最终职业方向。但是对于不同的公司而言，对 CTO 要求不尽不同（可以看看 2016年炒得比较火的某 CTO 离职事件）。所以 CTO 也会由不同的岗位成长而来。但是，并不意味着每个人都要以 CTO 为自己的职业目标。 图中黑体的岗位，都可以作为开发人员的职业方向。 对于还没有职业方向的的开发人员来说，选择好一个奋斗的方向， 非常关键。方向对了，就不怕路远！ 方向不清晰，则会做很多徒劳无功的事

软件体系架构师工作流程： 今天让我们看了《梦想改造家》回答这样的一个问题：结合《梦想改造家》中建筑者的工作流程谈及对软件体系架构师的工作流程？ 软件体系架构师在我的认知中，架构师的工作职责就是将我们所得到的工作需要进行总结，形成一个很好的软件架构（仿佛就是房屋中的一个模子）。但是通过和王平仲工作流程的对比，可以很简单的发现一个软件体系的架构师并没有我们想象的那么的简单。架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作，是软件项目的总体设计师，是软件组织新产品开发与集成、新技术体系的构建者，是从宏观上驾驭大型系统的战略家，是对软件项目中所有重要架构事情做出决策的人，是策略制定者、组织协调高手、称职的顾问与领导者。 因此，从中可以看出对于架构师的工作要求非常的严格。在此列出软件架构师的最为基本的工作流程： 1、 理解非功能性要求； 在《梦想改造家》中王平仲接受到任务后，直接去住户家中进行用户需求的获取。对于软件架构师来说来说是相同的，当他们拿到项目之后，第一步就应该去客户那里了解非 功能性需求。简单的说，如果架构师如果对于客户的需求都不了解，怎么做出客户满意的软件。而且大多数非功能性需求本质上是技术层面的，而且经常对软件架构产生很大 的影响，所以理解非功能性要求是架构师工作过程中非常重要的一个部分。 2、 根据用户需求，结合用户应用领域的实际情况，设计正确

架构师在软件项目中的作用是提供待解决问题的工作模型。架构师的工作是提供脚手架，开发人员将根据这些脚手架构建他们的代码，使应用程序所有部件都组合在一起。 在构建微服务架构时，项目的架构师主要关注以下3个关键任务： （1）分解业务问题； （2）建立服务粒度； （3）定义服务接口。 2.1.1　分解业务问题 面对复杂性，大多数人试图将他们正在处理的问题分解成可管理的块。因为这样他们就不必努力把问题的所有细节都考虑进来。他们将问题抽象地分解成几个关键部分，然后寻找这些部分之间存在的关系。 在微服务架构中，架构师将业务问题分解成代表离散活动领域的块。这些块封装了与业务域特定部分相关联的业务规则和数据逻辑。 虽然我们希望微服务封装执行单个事务的所有业务规则，但这并不总是行得通。我们经常会遇到需要跨业务领域不同部分的一组微服务来完成整个事务的情况。架构师通过查看数据域中那些不适合放到一起的地方来划分一组微服务的服务边界。 例如，架构师可能会看到代码执行的业务流程，并意识到它们同时需要客户和产品信息。存在两个离散的数据域时，通常就意味着需要使用多个微服务。业务事务的两个不同部分如何交互通常成为微服务的服务接口。 分离业务领域是一门艺术，而不是非黑即白的科学。读者可以使用以下指导方针将业务问题识别和分解为备选的微服务。 （1） 描述业务问题，并聆听用来描述问题的名词 。在描述问题时

在继续“四维架构设计方法论”这个话题之前，我们先来回顾一下前两篇文章的内容，以便我们更好地理解本篇： 如何建立架构师的立体化思维 ：阐述了架构设计会涉及业务、技术、系统和时间等几个维度，也建议从技术维度将应用分成七个层次。 如何设计分层架构和交互接口 ：介绍了分层架构的设计流程，以及接口设计方法等内容，还谈了领域、资源和数据三种模型的差别等。 接下来，我们来看看接口的分类方法和模块的设计方法： 接口类型的分类方法 如何确定图形用户接口（ GUI ）和应用编程接口（ API ）的分工呢？在收集业务需求的过程中，我们可以标识出发起这个需求的角色是人还是程序。如果发起需求的是人，那就需要通过 GUI 来满足，而如果发起需求的是程序，那就要通过 API 来满足。 图 8 接口类型的分类方法 模块的设计方法 架构设计流程第三步，按照功能相近的原则将接口划归到不同的模块当中。划分模块就会涉及到业务拆分。跟分层第一刀位置一样，我们选择业务层和领域层的交界处来做业务拆分。业务拆分需要跟业务专家一起来完成，通过这个过程可以确定出 Y 轴包含哪些业务系统，而这些业务系统的公用模块或系统将会被划分到业务层 X2 、领域层 X4 当中。 在做完第一轮业务拆分之后，我们就可以进入设计阶段，确定业务的交互流程，进一步明确业务层 X2 、领域层 X4 。然后并行启动交互设计和建模，其中交互设计是为了确定交互层