OpenUP核心原则三：关注，从开始起，就将注意力放在软件架构上，以减轻风险，并组织软件开发

关注，从开始起，就将注意力放在软件架构上，以减轻风险，并组织软件开发。

      演进的架构有助于团队处理复杂性，降低风险，并且更好的组织开发工作。

简介

      软件系统的架构即系统重要组件的组成结构，这些组件通过接口互相交互，同时，这些组件由更小的一系列组件和接口组成。

      如果没有架构作为基础，系统的演进将变得效率低下并且充满随意性。这种系统无论是扩展、重用，还是集成都变得十分困难，而且需要大量的重新开发工作。没有架构所提供的共同的技术关注点，团队的开发组织工作和思想交流也变得很困难。

      尽早关注架构可以减少风险并且更好地组织开发工作。

实践

基于当前的知识体系和需求创建架构

      正如爱因斯坦所说的，让一切尽量变得简单，直到无法更加简单。软件项目一般受资源约束，而且开发人员心中希望创建优雅解决方案的目标将导致系统比起干系人所需的系统更为复杂。面向未来不确定环境的可能出现的需求投入的开发努力可能会导致代码膨胀，这也将增加总成本和复杂性，而且没有多少真正的收益。
      我们需要创建这样的一个架构：面向干系人当前所知道的需求，解决干系人现实中的需求，并且提供适当的灵活性和运行速度。无论是出于哪种好意，我们都应该避免这样的目标，推测未来的需求并且构建一个过度设计的架构。过度设计的架构和创构一个灵活和具有扩展性的架构之间需要明确区分开来。例如，也许还没出现为系统创建一个三层架构的原因，但是系统也许会以我们无法预料的方式增加复杂的需求，因此我们需要设计这样一个架构。

把架构作为一种协作的工具

      开发人员之间缺乏对系统一致的理解将导致决策的不一致性，甚至还会出现相反的意见，这将导致项目陷入瘫痪。开发人员各自脑海中存在关于系统的模型，并且根据自己目标自行开发。
      创建和演进系统架构，采用这个架构让开发人员对脑海中的系统模型达成一致的认识。优秀的架构提供了共同的词汇用于系统开发过程中的讨论，为协作提供了便利。

提升抽象层次处理复杂性

      软件是复杂的，而且人们处理复杂性的能力是有限的。当系统不断变大，团队成员开发一个能够有一致理解的系统也变得困难，因为全局的把握也将变得困难。
      我们需要使用模型来提升抽象层次，把关注点集中在高层业务的决策，例如组件之间的关系和使用的模式，而不是关注细节。建模可以提升抽象的层次，而且让系统从各个不同角度看都更加容易理解。

采用松耦合、高内聚的组件 组织架构

      组件之间紧密耦合在一起将使系统变得脆弱，并且难以理解。软件的创建是昂贵的，因此，如果已经存在的组件能够被重用，这将大大减少创建一个系统所需付出的努力。
      采用组件的方式组织系统的架构，可以最大化组件的内聚，并且减少组件的耦合性。这种方式可以提升我们对系统的理解，并且增加灵活性和重用机会。

重用资产

      如果可以简单的实现重用，直接下载，或者直接购买，那么进行创建则是一种浪费。
      我们需要尽可能的重用已有资产。开发人员通常不愿意重用资产，因为这些资产并无法确切地满足他们的需求，或者是因为这些资产本身质量低劣。我们应该时刻准备着权衡认识到使用已有资产带来的成本节约，甚至是这些资产要求你对架构进行适当的调整或者减少一些约束。