架构师

　　通过课堂上观看梦想改造家这个节目，我想到了软件架构师的工作流程，在梦想改造家中，王仲平这个建筑师首先是了解用户需求，然后根据用户需求制定相应的方案和改造计划，其中考虑到了用户的方便性，安全性，重用性，空间利用性。对于我们软件架构师来说，同样如此，非常相似。　　 　　软件架构师在需求分析阶段介入。在这一阶段软件体系架构师与软件需求人员一起将所有的需求从不同的级别分层数理列表归纳总结建立跟踪矩阵，并划分为不同的类型进行数理列表归纳总结建立影响分析表，找出不同需求类型之间的相互支持、相互制约关系的影响。并同需求分析人员共同建立需求规格说明书。 第二步是确定对架构关键的需求，软件架构师将所有的需求进行筛选，在深思熟虑之后做出合适的需求权衡和取舍，最终确定对软件架构其关键作用的子集，控制架构设计时需要详细分析的用例个数，找到架构的重点非功能需求。要根据需求确定架构目标（即是组成设计过程、确定使用范围并确定什么时候该结束的因素）。并且要了解架构的消费者。要确定架构是否会被其他设计师、开发人员、测试人员、业务人员或管理人员使用。确定架构涉众的需求，以让架构更为成功、更有影响力。了解条件限制。了解技术限制、使用限制、和部署限制。从一开始就要了解这些限制，这样你才不会在将来遇到一些意想不到的麻烦。为后面的工作打下坚实的基础。 第三步进行概念性架构设计，首先分析关键用例和有用例规约，运用鲁棒图

软件架构设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单。本文从架构师职责、软件架构定义、设计架构、评估架构、架构管理等方面来描述了解软件架构的含义和怎样设计软件架构。 软件架构师的职责 架构师分为以下几大类：业务架构师、主题领域架构师、技术架构师、项目架构师（J2EE架构师、.NET架构师等）、系统架构师。 1、 架构师 的职责主要体现 架构师的职责就是设计一个公司系统的基础架构，并提供关于怎样建立和维护系统的指导方针。具体来讲，架构师的职责主要体现在以下几方面： 1）、负责公司系统的架构设计、研发工作。 2）、承担从业务向技术转换的桥梁作用。 3）、协助项目经理制定项目计划和控制项目进度。 4）、负责辅助并指导系统分析开展设计工作。 5）、负责组织技术研究和攻关工作。 6）、负责组织和管理公司内部的技术培训工作。 7）、负责组织及带领公司内部员工研究与项目相关的新技术。 8）、管理技术支撑团队并给项目、产品开发实施团队提供技术保障。 9）、理解系统的业务需求，制定系统的整体框架（包括、技术框架和业务框架）。 10）、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。 2、 构架设计师 必须具备的技能 经验：既包括在问题领域的经验（通过彻底了解需求）

如果说架构的本质是管理复杂性，那么抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。 1、抽象思维 抽象其实是这样定义的： 对某种事物进行简化表示或描述的过程，抽象让我们关注要素，隐藏额外细节。 在系统架构和设计中，抽象帮助我们从大处着眼（get our mind about big picture），隐藏细节（temporarily hide details）。抽象能力的强弱，直接决定我们所能解决问题的复杂性和规模大小。 软件系统架构设计和小朋友搭积木无本质差异，只是解决的问题域和规模不同罢了。架构师先要在大脑中形成抽象概念，然后是子模块分解，然后是依次实现子模块，最后将子模块拼装组合起来，形成最后系统。所以我常说编程和架构设计就是搭积木，优秀的架构师受职业习惯影响，眼睛里看到的世界都是模块化拼装组合式的。 2、分层思维 除了抽象，分层也是我们应对和管理复杂性的基本思维武器，如下图，为了构建一套复杂系统，我们把整个系统划分成若干个层次，每一层专注解决某个领域的问题，并向上提供服务。有些层次是纵向的，它贯穿所有其它层次，称为共享层。分层也可以认为是抽象的一种方式，将系统抽象分解成若干层次化的模块。 3、分治思维 分而治之(divide and combine或者split and merge)也是应对和管理复杂性的一般性方法，下图展示一个分治的思维流程

软件架构师的架构流程 架构的定义：一个程序和计算系统是指系统的一个或多个结构。结构中包括软件的构建，构建的外部可见属性以及它们之间的相互关系。 软件架构师能够通过软件架构分析设计在满足规定需求方面的有效性、在设计变更相对容易的阶段，考虑体系结构可能的选择方案、降低与软件构造相关联的风险。 软件架构的优点：软件架构能够满足系统的品质、架构设计使受益人达成一致的目标、架构设计能够支持计划编制过程、架构对系统开发的指导性。架构设计为复用奠定了基础、架构设计能够降低维护费用、架构设计能够支持冲突分析。一个好的架构是高内聚、低耦合的，既可以作为一个完整的可交付模块，也可以“打碎”了重组； 一般的软件开发过程包括五个阶段：概念化阶段、架构设计阶段、并行发与测试阶段、验收与测试阶段。但这是项目经理、架构师、开发人员、测试人员等所有人公同遵守的过程，对于软件架构师的架构设计及开展非常依赖其上游活动，这些上游活动包括需求分析和领域建模。需求分析，在没有全面认识需求并权衡不同需求之间相互影响的情况下，设计出的架构很有可能有问题。领域建模，领域建模的目的是透过问题领域的重重现象，捕捉其背后最为稳固的领域概念及这些概念之间的关系。概念性架构的设计过程：确定对架构的关键的需求。对功能需求进行筛选，对非功能需求进行综合权衡，最终确定对软件架构起关键作用的需求子集。 概念性构架设计：分析关键用例的用例规约

前言： 框架开源后，学习使用的人越来越多了，所以我也更加积极的用代码回应了。 在框架完成了：数据库读写分离功能 和 分布式缓存功能 后： 经过三天三夜的不眠不休，终于完成框架第三个重量级的功能：自动化分布式缓存。 源代码已经提交，源码地址见： 终于等到你：CYQ.Data V5系列 （ORM数据层）最新版本开源了 记得很多年前，大概2010年左右吧，CYQ.Data框架进入快速更新版本阶段的时候， 那时候的我会经常在一些技术群里有意无意的说起自己的框架，然后群里总有那么一些自我而自负的人会说： 你的框架有啥优点呢？我为啥要使用你的呢？看你这起的框架破名就不想使用了.... 可能是不擅于表达... 可能是不屑于回答... 可能的确是没啥优点好说... 忽然就有一种蛋蛋的忧伤... 后来就转变了心态，转收费，小众就小众，彪悍的人生，不需要解释...... 后来的这些年： 创业的经验，学会了从产品的思维让框架的使用简单化。 技术的沉淀，思考了从架构及分布式思维设计框架。 项目的历程，促使了框架应用场景的丰富化及自动化。 框架的优势： 如果现在有人问我框架和其它ORM比起来的的优势，我只能说，能不比么？因为早已经不在一个Level上了。 不过既然你们诚心诚意的问了，我就大发慈悲的说了，哈： 5年前V4系列版本图： 不过我并不想把这些功能当成框架的优势，因为我觉技术沉淀了一定岁月，只要努力

01 架构师岗位职责 曾有人这样形容架构师的重要性：架构师的工作就像是他打造一棵树的主干和枝干，然后程序员们让这棵树上长出树叶和果实。 架构师，是一个既需要掌控整体又要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的团队领导型人物，他需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。 架构师职责简单来说有三点： 1、确认需求与拆分系统 在项目开发过程中，架构师需要依据用户需求，将完整的系统拆分为子系统和组件，形成不同的逻辑层或服务，确定各层的接口、层与层相互之间的关系，对整个系统分层进行“纵向”分解，对同一逻辑层分块进行“横向”分解。 2、技术选型 通过对系统的一系列的分解，最终形成了软件的整体架构，依据整体架构需要进行技术选型。 3、制作技术规格说明 在整个研发过程中始终保持与开发人员保持沟通，以保证开发者依照原定的架构意图去实现各项功能。 02 架构师必备能力 1、架构师能力图谱 架构师的技术实力要强，具备技术广度，同时，还要注重其它软实力，譬如抽象能力、应急能力、管理能力、沟通能力、技术实力等。 2、架构师必知必会技术 架构师除了能撸一手高质量代码，至少精通1-2门技术，还要具备足够的技术广度，从软件到硬件、开发到测试、运维到安全等等，都要面面俱到去了解掌握。当然了，人的精力是有限的

如何循序渐进向DotNet架构师发展 以下文章为转载，原文见【 如何循序渐进向DotNet架构师发展 】 blueski推荐 [2006-7-17] 出处：CSDN 作者：人月神话blog 微软的DotNet开发绝对是属于那种入门容易提高难的技术。而要能够成为DotNet架构师没有三年或更长时间的编码积累基本上是不可能的。特别是在大型软件项目中，架构师是项目核心成员，承上启下，因此RUP方法论也认同以架构为核心，体现4+1视图在整个软件开发过程中的重要作用。架构人员既要精通技术，又要熟悉业务，而且基本对软件生命周期各阶段的相关技术都需要有相关的积累和知识储备，而这些不经过多年的磨练是很难达到这个高度的。 要成为一个合格的架构师首先必须是一个合格或优秀的编码人员，对于开发来讲编码始终都是最重要的一项技能，在编码过程中只要自己善于去思考和分析问题，就可以多学到很多相关的知识和技术。所以我们在开发过程中一定要注意新知识和新技术的学习，前人经验和成果的学习。编码过程中应该去思考的一些问题有： 1.在编码过程中自己是否做单元测试，是否使用相关工具做单元测试，如果没有的话是什么原因无法把单元测试做起来？ 2.自己编码的泄露率情况，编码泄露的BUG的原因分析 3.是否有意识的对代码进行重构，重构过程中是否引入了相关设计模式的思想？ 4.是否对C#语言的一些高级特性进行学习，如反射调用，异步处理等

http://blog.csdn.net/aspop/archive/2006/01/21/585823.aspx 在比尔·盖茨的众多称谓中，据说他更偏爱“首席软件架构师”。同样，在网易创始人丁磊名字前，也有“首席架构师”这样的称谓。对于企业来说，架构师就是灵魂的创造者。那么企业架构师该怎么来实现其“架构”企业的职能呢？尤其在设计企业IT策略时，该怎样体现架构师的价值？它与CIO之间存在着怎样的关系呢？ <noscript></noscript><noscript></noscript> 架构师是企业建筑师 摩托罗拉的副总裁Toby Redshaw说，架构师是“IT策略中的中枢”，而且这一角色对公司的影响确实非常大。当Toby Reshaw在2001年进入摩托罗拉并担任其策略暨架构副总裁时，他俨然一位购房者对一套摇摇欲坠的公寓进行估价一样。他并不是仅仅只作些表面上的修改，而是拟定了一个重建摩托罗拉整个基础结构的计划，这个计划可以彻底修整公司的基础建设。 就像一个建筑师设计一幢房子一样，Redshaw拟出了一张技术构架蓝图，一座技术性的建筑，以便使被他称作“如意大利面条般错乱的应用程序，机器和管线”那些东西变得井然有序。他说，只要选择了正确的架构策略并用对了人，摩托罗拉就可以用比以前更快的速度生产出大量应用软件，而且可以减少维持重叠系统的费用。 Redshaw说：

在一个较大规模的软件组织里，一般都有项目管理师、软件架构师、系统分析师、软件设计师、测试工程师、数据库工程师、程序员、过程改进、质量保证等不同的职位。在这些职位中，人们容易混淆的是系统分析师和软件架构师。 对于系统分析师的角色，业界有两种观点，一种是把系统分析师当成既懂技术又懂管理的全能冠军，另一种是把系统分析师当作需求分析师，而架构师才是灵魂。那么，系统分析师和软件架构师在角色方面的分配究竟有什么区别呢？ 对这个问题进行整理，分析如下：当软件规模比较小时，系统分析师所完成的工作是把真正的业务需求( 这个需求不是指客户简单所说的哪一个功能，而是需要去挖掘的，可能是潜在的但又是系统必需的，条例清楚、逻辑清晰的业务功能。 而且需求不仅仅只是来自业务上的，系统所依赖的运行环境也会产生一些需求)转换成计算机可理解、可实现、可计算的模型。但由于现在的系统规模越来越大，复杂程度越来越高，而且应用领域也越来越广，所以很难由一个工种的人来全面完成这项艰巨的任务。在具体的软件设计过程中，现在把它分解为由系统分析师与软件架构师合作共同来完成这一任务。其中系统分析师侧重的是前一部分的工作，软件架构师侧重的是后一部分的工作。 系统分析师的主要工作内容包括业务需求分析、系统需求分析、可行性分析以及建模等，再及时与项目经理(项目管理师)、软件架构师以及老板商讨，分析项目具备的特点、成本、风险等，考虑现实的模型

今天给大家带来一篇自己翻译的干货《软件架构师之路》。本周Github上升很快的项目。其内容对致力于成为软件架构师（不论前后端）的同学应该都会有极大的帮助。 项目地址: 中文地址 https://github.com/gamedilong/SoftwareArchitect-CN 原文地址 https://github.com/justinamiller/SoftwareArchitect 如果有看完英文原文，发现本文翻译内容中存在问题或者错误的欢迎到中文Git地址PR，如能够对大家起到一定的帮助也欢迎star 内容 什么是软件架构 软件架构的层次 软件架构师的典型工作内容 软件架构师的重要技能 架构师的技术路线图 相关书籍 什么是软件架构? 软件架构师是一名软件开发专家，他可以进行高层设计选择并决定技术标准，包括软件编码标准，工具和平台。 (出处: 维基百科:软件架构师) 软件架构（architecture）是一个系统的基本组织，由其组件、它们之间的相互关系和环境以及决定系统设计和演化的原则来表示。 (出处: 软件架构手册) 软件架构的层次 软件架构可以被抽象的分为几个层次，不同的层次对技能的要求不同。对层次有很多不同的划分，我最喜欢如下这三种划分: 应用级 : 最低层次的架构。聚焦单个具体的应用。 非常注重细节, 底层设计。 沟通仅限入单个开发团队。 解决方案级 : 中级别的架构