用微软.NET架构企业解决方案 学习笔记（一）

　　

　　当今的架构师和架构

 

　　

引言

　　在计算机的早期，大概是1960年左右，硬件的花费在软件之上，是占主导地位的。40年之后，我们发现情况发生了极大的变化。

　　因为工业的进步，硬件的成本急剧的下降。另一方面，软件开发的成本因为个性化企业级应用开发的复杂性而急剧上升。对公司来说，便宜的硬件使得为他们的信息系统增加越来越多的功能是值得的。最初一些独立的系统，相互之间没有连接，也很少会共享数据，在多年之后，变成了复杂的系统，功能和模块之间相互连接。

　　这种情况创造了一个需求，在进行这样的系统设计的时候，需要一系列的规范来指导工程师。

　　从建筑行业借用过来，“架构”一词用来描述计划、设计、实现软件系统的技能，是合适的。然而，在软件开发中，架构不像在建筑行业中需要那么多的艺术性质。设计良好的建筑对眼睛和功能来说，是令人愉快的。软件架构在主观方面会少一点。

　　

正文

　　1、什么是软件架构

     “架构"一词最初被用于软件工业中，是表达在进行代码开发之前需要计划和设计。但是，在架构一个可用的软件系统和架构一个适于居住的建筑之间还是有本质的区别的。

      很明显的，在架构建筑的过程中，我们会考虑建筑是否会砸到人。但是在软件中，通常有大量的金钱可以改写一个架构。在建筑业中，设计一定要以极其详细的计算和蓝图为基础，才能完成。在软件开发中，你可能会倾向于更加敏捷。在十几年前，预先设计的方法在软件行业也是非常普遍和流行的。但是，十几年过去了，这种方法增加了开发成本。因为在部署之前，软件可以进行高效和安全的测试，相比预先设计，敏捷占了上风。

      今天，建筑行业的架构和软件行业的架构已经不像很多年前那么相似了。在很多字典中，软件架构被描述为：在一个计算机系统中，组合、整合、多个组件之间的联系。但是，他还是比较抽象的。

      软件行内人通常会接受另一个解释：将系统分解为很多小块，然后放在环境中。

      2、谁是架构师

      架构设计基于对需求的分析。分析可以确定系统需要做什么，架构可以确定如何做。架构师是需求和详细设计之间的纽带，但是架构师的职责是什么呢？需要哪些技能呢？

      2.1架构师的职责

      根据ISO标准中定义，架构师是对系统架构负责的人、团队或者是组织。架构师与分析人员和项目经理相互配合，对系统评估和提出建议，协调一队开发人员。

      架构师参与开发的整个过程，包括分析需求和架构设计、代码实现、测试、集成和部署。

      主要的职责包括：

      1）理解需求

      在软件项目中，在架构师参与之前会发生一些其他事情。一群分析人员，IT部门的管理者，行政部门会开会、讨论、评估、商量。一旦一个新系统的需求被确定下来，预算到位，分析人员就会基于自己的业务知识、企业的流程、环境和终端用户的反馈引出典型的需求。

      需求列表准备好之后，项目经理就会和架构师碰头，将需求交给架构师，“这就是客户想要的，你去构建一下”。

      架构师理解需求，尽力在设计中满足和采纳它们。

      2）分解系统

      在需求的基础上，架构师将系统分解为多个子系统。在这种情况下，架构师会展望一下逻辑层和服务层。然后基于环境，确定层之间的接口，和其它层之间的关系，系统需要的服务级别。

      整体设计与企业的目标和需求保持一致。在一些特殊地方，由需求来驱动整体设计，而不是整体设计领导需求。

      架构会包括一些通用的指导原则，要求最小化模块之间的耦合，保持模块的高内聚，保证每一个模块有一个清晰的职责。

      架构的结果还会满足一些非功能的需求，例如:安全、伸缩性。最后架构师还会指定一些战略性的东西，例如：每一个开发者的任务、或者是团队的任务，或者是子系统的组件。

      3）确定和评估可用的技术

      在理解了需求和设计了系统的层次之后，下一步就是用具体的技术和产品计划逻辑组件。架构师应该清楚和项目有关的产品和技术的成本和好处。架构师推荐一些对于项目来说，性价比较高的产品和技术。架构师不决定技术，只是以自己的知识为基础，推荐技术。

      那么谁来决定使用架构师推荐的那种技术呢？显然是项目经理，或者是预算的管理者。架构师的建议可能被接受或者被否决。

      4)明确详细设计

      架构师最后的职责就是确定详细设计，详细设计是架构师和开发者进行交流的结果。详细设计可以以多种形式存在，UML图、文档、Viso图，甚至是原型。沟通对于一个架构师来说是至关重要的。沟通发生在架构师和开发者之间，也发生在架构师和项目经理以及业务分析人员之间，但是不是和用户。对架构师来说，一个良好的技术就是语言清晰。

     

结论

      架构是一个被广泛使用的词汇，拥有相当多的定义。

      架构设计从功能和非功能需求出发，功能由业务分析员收集，架构师理解。