.Net企业级应用架构设计之当代的架构师和架构

前段时间刚刚看完了《Microsoft .Net企业级应用架构设计》一书，以后陆续的分享作者在书中的精华，简明扼要的进行总结和概述。同时这本书推荐给有兴趣的童鞋。

软件架构到底是什么

每次遇到软件项目时，我们都会创建一个解决方案。这个过程就叫做架构设计，而架构设计的最终产物就是软件架构。在软件领域，架构就是指为客户构建系统。

软件架构分为隐式和显式两种。隐式架构可以看作是一系列原有经验，其他类似项目中学到的技巧以及将抽象概念进行组织并应用到手头的能力。若项目干系人（项目干系人的定义是所有对创建系统感兴趣或关注的人，包括系统的创建者架构师、开发人员、测试人员、以及产品接受方、最终用户、分析师、审计人员、首席信息官等。）想法过于精细，以至于无法用经验和头脑中的想法来处理，则需要用显式架构。

优秀的架构

软件架构的关键点是软件应该符合项目干系人的期待。期待可以分为功能性和非功能性需求两种。若想让软件系统满足目标，我们必须遵守一种架构上的约定。这个架构的约定就是你要认识到无论对于何种系统，一些重要的决定必须在开发的初期确定，如同在城市的规划建设中一些关键决策一样，例如，不能在应该造桥的地方建造摩天大楼。软件系统必须着眼于系统的组织以及系统基础设施的分布，随后即可对系统进行设计和描述。设计需要在早期作出一些重要决定，而描述系统则需要给出多角度下系统的样子，每个描述都会覆盖到系统的一些职责。

系统不能脱离上下文，且上下文也通过开发以及操作上的决策影响系统的设计。系统是为了解决问题并满足项目干系人要求而存在的。项目干系人的要求分为功能性（功能性需求是指系统需要做的事情，即系统需要为完成特定的任务和达到用户的目的提供那些功能，并且这个软件需求必须“清晰、正确、避免二义、明确且可检验”）和非功能性（非功能性需求是指那些最终系统整体上的需求，但这些需求并不属于功能方面）两种，以及诸如安全性、可测试性、性能、可靠性、和可扩展性等其他方面。

架构的核心在于其包含的组件和类型，以及最终映射成的二进制文件、相互的关系和依赖、使用场景和关键操作的操作流程。描述架构的最流行的方法就是使用UML图表。通过UML的一系列使用，即可对架构进行不同角度的描述，并抓住其核心部分。

什么属于架构，什么不属于

在设计架构之初，最需要明白的是什么属于架构，什么不属于！很多系统都会被设计成一系列的组件，组件与组件之间有着不同的通信方式和依赖关系，所以首先我们要不断的拆分各个子系统通讯的过程，最小化系统的结构和关系。其次我们需要定义结构和现实之间的边界，这个过程非常重要，边界定义了开发团队中不同成员的职责，也就是给出了架构师和开发者之间工作的区别。在得到了一个个封装了特定行为的黑盒以后，我们也就达到了架构和现实之间的边界，封装特定行为的黑盒是一小段功能，其实对其重构也不会对整个架构伤筋动骨。而在封装特定行为的黑盒之上，应该是架构相关的内容，这可能属于预先定义的、不会轻易改变的决定。最后就是处理不会轻易改变的决定，一旦进入开发流程，软件系统中总有一些方面和功能不会轻易改变，若你发现有些东西比你想象中更加易于改变，那么它就不再属于架构了。

在架构过程中，架构师的主要职责是接受需求、拆分系统、确定并评估技术以及编写详细说明书。

1.接受需求：在一个软件项目中，有几件事情在架构师参与之前就开始做，很多分析师，IT项目经理，和主管人员聚在一起，开会、讨论、评估、并协商，随着版本的更新和资金到位，分析师会根据其对业务、公司流程、上下文、以及最终用户反馈的了解来编写需求。完成需求后，会将该需求对架构师交付，架构师将接受需求，随后努力让其可以实现，并给出设计。

2.拆分系统：拆分系统时架构师需要评估各种架构模式，分层是其中最常见的，分层能够将功能按照水平方式拆分开。分区则是另一种技术，所有的部分都在同一个逻辑层次上，围绕着一些共享的实体。最红产生的结构必须满足通用的指导规范，而最终的架构同时也由一些非功能性决定，例如安全性、可伸缩性等，这些都会影响和约束架构师在设计解决方案时的选择。

3.确定并评估技术：初步确定了架构接下来确定并评估技术，需要注意的是架构师并不选择技术，只是根据其掌握的技术给出提议。那么谁决定最终使用哪项技术、哪个产品呢？一般来说，这是由项目经理或者管理预算的人决定的。架构师的提议可能会被接受，也可能会被拒绝。

4.编写详细说明书：架构师最终负责系统的开发，在这个过程中，架构师需要与开发者沟通，也需要与项目经理和分析师沟通，或许还要和用户沟通。因此架构师很重要的一个技能就是语言要明确清晰。（突然感觉架构师是一个比开发更苦逼的位置）

ps：微软公司定义了四种架构师：企业架构师、基础架构师、特定技术架构师、解决方案架构师。从文字表面即可看出特定所指，不做解释。

软件开发模型

在开始软件项目之前，首先应该选择一种适合项目，且能够配合项目相关人员水平和态度的开发方法。一个软件开发方法就是一系列应用到软件开发过程中的最佳实践。软件开发方法能够帮助人们管理并实现项目。

谈到最佳实践，让我想到《黑客与画家》一书中充满讽刺的一段描述：【在大型组织内部，有一个专门的术语描述这种跟随大多数人的选择的做法，叫做“业界最佳实践”。这个词出现的原因其实就是为了让你的经理可以推卸责任。既然我选择的是“业界最佳实践”，如果不成功，项目失败了，那么你也无法指责我，因为做出选择的人不是我，而是整个“业界”】。

言归正传。当前存在两种主流的开发模型：传统模型和敏捷方法。当然，现在很多团队都宣称自己是敏捷开发，到底是不是，天知地知，他自己知。

瀑布模型是最被人们熟知，也是最传统的方法。瀑布模型的设计理念和城市规划一样。也就是说在开始编写代码之前，设计必须全面完成，且不能更改。瀑布模型是一种简单且纪律性强的方法。对于一些绝大多数项目而言，有些不切实际，因为你几乎不可能在项目开始就得到所有的需求，并且还会发生一些不可避免的情况。考虑到这些，瀑布模型多年来有一些改进，其中设计和实现这两个步骤有着一部分的重叠。

敏捷方法作为瀑布模型的改进，迭代开发是一个循环的过程，它主要强调渐进的方式开发软件。迭代开发是敏捷开发的基石。敏捷方法中，人是作为项目中最重要的部分。正如敏捷宣言描述，敏捷方法更关注于在一起工作和交流的人。有时客户和开发者在一起工作，因此敏捷流程就是敏捷的应对变化。

软件开发中较为流行的敏捷方法就是极限编程。Scrum是另一种流行的敏捷方法，不过与编写代码相比，他更加关注于项目的管理，Scrum并没有限定与之配合的软件开发模型，却能够很好的配合XP来编写代码。

对架构师的误解

1.架构师等于分析师：架构师也许会参与到项目干系人的讨论，但仅此而已。通常而言，分析应该属于项目领域中的专家。在小公司有可能一个人身兼两职，也就是说，公司里的某个人足够了解业务，还能写出功能需求并将其转换成为开发者所使用的详细说明书。不过两者的角色和职责仍旧是不同的，虽然这两种技能可能会同时出现在一个人身上。

2.架构师就是项目经理：架构师负责系统的架构和协调，并在开发过程中提供指导。项目经理作为项目干系人，管理项目的进行。两者分工截然不同。不过身兼数职也不罕见，这种情况在大公司少见，小公司很常见。

3.架构师从不编写代码：一种看法认为架构师在需要的时候才会出现自开发团队中；另一种开发是架构师都是天生的开发者。实际上架构是可能不会编写太多的产品代码，但确实会写很多其他代码。在软件领域中，架构师和开发者的成长途径十分相似。开发者的经验越丰富，他就会越喜欢一些设计方面的问题，并有着充分的理由。架构师越是不经常编程，就会越加失去他在开发者眼中的威信，这就形成了一个恶性循环，但是使用敏捷开发方法，情况就会好很多。

相关博客：

• .Net企业级应用架构设计之当代的架构师和架构
• .Net企业级应用架构设计之UML
  
• .Net企业级应用架构设计之设计原则和模式
• .Net企业级应用架构设计之业务层设计
• .Net企业级应用架构设计之服务层设计
• .Net企业级应用架构设计之数据访问层
  
• .Net企业级应用架构设计之表现层设计

、