一、什么是架构
    在牛津高阶词典（第7版）中，架构（architecture）一词的解释是：the design an structure of a computer system，而架构师（architect）一词的解释是：a person who is responsible for planning or creating an idea, an event or a situation。
    针对于企业应用，依据不同的关注点，架构可以分为如下几类：
    业务架构（Business Architecture）：关注于业务及其流程；
    应用架构（Application Architecture）：关注于应用系统设计；
    基础架构（Infrastructure Architecture）：关注于基础技术；
    数据架构（Data Architecture）：关注于数据存储及其规划；
    这里所说的企业应用架构，即属于应用架构，包括如下几个部分：
    1.目标和愿景。即应用系统所面临的问题域。
    2.评价指标。从哪些纬度和指标来评价和度量解决方案。
    3.原则和方法论。为解决这些问题，所采用的原则及其方法论。
    4.技术架构。架构的技术层面，给出相应的设计以及结构，描述应用系统。
    5.组织因素。架构的组织层面，组织的各个部分如何参与。
    二、架构的目标和愿景
    1. 架构的问题来源
    （1）外部，客户要求包括了业务和技术上。
    （2）内部，组织管理、项目管理和技术发展上。
    特别的，架构需要解决的非业务问题包括如下：
    A.系统目标：系统性能，稳定性等。
    B.项目目标：开发成本，项目质量等
    C.项目过程：需求的不确定性和开发过程的团队协作性，即所谓的开发管理。
    2. 架构的核心问题
    问题可分解为两种类型，业务上和技术上。
    （1）业务上。问题域分解为，逻辑的纵向抽象层次，以及逻辑的横向模块分解和集成。
    （2）技术上。问题域分解为，纵向的技术主题，以及横向的技术职责的分解和集成。
    A.领域化
    传统的架构模式是三层或者四层模式，虽然从技术上有效的横向分解系统结构，但对业务模型如何建立，如何进行层次间传递，模型间关联关系，以及与服务逻辑耦合等问题没有给出进一步的细化，也带来了很多问题。
    此外，在传统设计方法下，分析模型和设计模型的转换也是一个大的问题。
    B.组件化
    实施组件化或者说模块化，其需求分为两个层面。
    1.内部管理，可以帮助开发过程中进行业务切分，帮助控制进度，降低风险，以及财务分析；对于大型复杂的项目，也有利于知识的传递和积累。
    2.销售需要，All in one的系统因不符合发展趋势而不利于销售；组件化有助于产品销售，可以针对客户，将若干组件打包销售，同时减少集成的风险。
    C.产品化
    C.1 定制化问题
    定制化问题的由来：1.面向行业的应用通常没有标准，或者完备的标准；2.通常产品的开发是针对于通用或者公共需求，不针对于特定客户；3.而一个确定的客户，其自身的业务差异和管理差异导致需求的差异性。
    这种现象尤其在缺乏标准的行业应用中，以及系统的产品化过程中。
    传统的简单的解决方式是为每个客户单独维护一个系统分支，在此情况下提供维护和升级，则维护成本巨大；因此如何解决领域的定制化就成为一个重大问题。
    C.2 升级问题
    领域需求每次进一步的挖掘和实现，都意味着领域的升级。但升级面临的诸多问题:数据迁移,旧版本的兼容问题，依赖关联等等，在组件化和定制化情况下，还面临定制化兼容和冲突检测。
    C.3 国际化问题
    （1）文本消息国际化
    国际化消息没有直接呈现，而是中间存储后呈现；
    （2）布局国际化
    阿拉伯人是从右到左；
    （3）业务时间，跨时区；
    （4）计量单位，多币种；
    D.平台化
    应用系统可以分为两个内容：应用程序和基础设施。应用程序处理业务问题，而基础设施处理技术问题。
    来自客户的要求是包含业务和技术两个方面。其中技术上包括两种“定型和定性”，其所需的知识和技能是不同于业务上的；
    此外，内部管理也提出相应的要求。由于技术的发展和业务发展之间的不同步，对于一个产品而言，同时存在技术升级和业务升级两个需求。而同时升级存在较大的成本和风险。
    同时对于一个产品来说，技术方面需要较强的适应性，能够低成本上的适应客户的特别要求。
    因此有效解藕技术和业务两个部分成为必然。
    3. 架构的应用问题
    A.事务管理
    数据一致性问题出现的原因通常是开发过程中，由于错误的并发和事务控制导致的；而在业务过程中也存在错误的业务操作情况。
    B.并发处理
    不同的业务应用存在不同的并发场景（并发度以及存在的业务依赖），因此业务上需要明确原则和方案；而不同平台所支持的并发方式和能力也不相同，则采用一定框架支持有助于简化问题。
    C.集成能力
    业务应用所面临的集成问题不同，包括不同的集成环境：外部系统，内部系统，遗留系统等；不同的集成模式：基于文件，基于数据库表，基于消息等，导致所需的集成方法及其能力也不同。
    4. 架构的设计问题
    分析设计和开发实现存在着一定的差异性：分析设计属于知识级，而开发实现属于操作级的。
    分析设计是需求和实现的中间桥梁，因而设计必须解决系统边界的合法性，内部逻辑解藕的合理性和实现的可达性（设计的类方法为实现的30%-70%）。而开发实现需不断重构代码，采用约定和框架能力等技术手段解决开发的实际问题，解决程序级别的健壮性，可读性，可维护性以及可测试性。
    传统的方式，分析设计存在于文档中，而开发实现存在于代码中。两者的割裂导致沟通的困难，也导致了开发工程中具大的风险——分析设计和最终开发实现的不一致性。
    三、架构的评价指标
    1. 财务角度
    在传统的财务核算机制中，系统或者产品的开发通常属于成本中心，对于IT企业来说，电脑设备，办公室等属于沉没成本，而IT人员的工资属于可变成本，是成本的核心部分，为了控制成本，就需要减少项目的开发时间。
    因此架构一个重要的关注点在于控制开发成本和维护成本，通常讲维护成本是开发成本的3倍。降低开发成本核心，在于提高效率、提高适应需求变化的能力。
    2. 技术角度
    技术角度评估架构很难说。
    四、架构的技术层面
    （一）基础手段
    提高开发效率和品质的基本手段是分解——即充分的分离系统中不同的关注点，好处不用说了，可以并发的工作，每个人面对的问题都简单而容易操作。而与分解对应的集成，只有提供了好的集成能力，分解才成为现实，而只有分解了，才能清晰的提供业务更多适应性。
    分解和集成的手段分为编程语言和技术框架两个层面。所谓语言就是强框架，而框架就是弱语言。
    A. 开发语言
    现代面向对象的语言提供如下能力：抽象和派生能力，以及接口隔离能力。实际提供两种分解和集成能力：
    （1）把逻辑分解在两个层次中，而通过继承的方式把两个部分集成在一起。
    （2）把逻辑的外观和实现分解在两个地方，而通过接口实现的方式把两部分集成在一起。
    另一种语言AspectJ或者C#语言2.0之后提供的特性：把流程逻辑，分解在不同的地方，而通过签名匹配，利用代码生成的方式来把几部分集成在一起。
    B. 应用框架
    然而语言提供的集成能力，毕竟底层，而且有限，扩展起来也格外小心。因而技术框架提供另外的集成能力就格外重要：
    （1）对象关联关系的分解和集成，如Spring提供容器管理能力
    依赖注入对于依赖关系是适合的，对于服务间，技术层次间都是适合的（因为无状态）；但对于聚合（整体和部分）的关系——主要是领域模型（有状态的）——则不合适；
    （2）模块间关联关系的分解和集成，如OSGi，ESB等
    （3）流程逻辑的分解和集成，如Spring Web Flow以及jBPM。
    （4）不同系统的类型分解和集成，如Spring利用动态代理提供的Exporter模式。
    （5）模式的封装集成，设计应当是面向服务的设计，但是服务的暴露方式以及模式可以有很多种，比如API，Web Service，RMI，以及Command模式，Event模式等，框架应该利用动态代理等技术对于这些服务暴露方式，模式进行封装。
    C. 分析设计
    设计中涉及到的组合方式，包括类（接口）组合，继承组合以及产生组合三种。三种组合各有优缺点，设计时适应不同场合。这就涉及到现有面向对象的设计粒度：类（第一公民）和方法（二等公民）。
    类（接口）组合实际上复用的是类一级粒度的设计，而继承组合本质上是一种有方向的组合，复用的方法一级粒度的设计，提供与或非的逻辑操作。而产生组合，例如AspectJ，也是在方法一级粒度的设计复用。
    因为继承组合复用在方法一级的粒度上，因而其更适合存在嵌入式，最低粒度的差异性的设计中，借助于虚拟机的支持，无需额外工作。而类（接口）在类一级上，更适合在更高一级的逻辑复用上；其实不一定需要接口，普通的类也可以，但是在这一级粒度的差异性替换，采用接口优于类，因此称为类（接口）组合；接口是类（接口）组合的编码需要；对于接口一级，需要通过框架的集成和适配来提供差异性的设计。产生组合其实也是在方法一级，不过更关注于广泛的横切面，同时由于现有的语言对它的支持不同，Java需要额外的编译器，而.Net则是在内置编译器上支持。
    更高一级的组合是组件组合。对于组件边界的设计，遵从两点：严格把关设计和代码优先。接口优先的设计通常导致成本太高，实践中会导致开发人员在项目的进度压力下把代码写在不合适的地方。
    D. 开发方式
    常见的开发方式可以归结为3类：开发式编程（Programmatic programming），声明式编程（Declarative programming）和产生式编程（Generative programming）。
    E. 小结
    通常语言作为架构的基础，语言的设计带来的好处远远高于框架和模式，但其引入和更换也是有巨大风险的；而通过提供强大的框架能力，框架尽可能多的完成技术问题，并通过元数据，模式以及约定降低业务和框架的耦合。避免因为框架升级带来不必要的成本。
    Meta Programming的最高层次是语言级别直接解决，比如，Smalltalk, Ruby, Python, 还有其他Reflection支持的非常好的语言。甚至STL等template技术，也可以算作语言级别。 Code Generation 是最低级别的Meta Programming解决方案,技术含量也最低。这个级别必须超越，才能够真正达到质变，完全跳出概念炒作的层次。
    从技术手段上，提高开发效率的另外两个手段是代码生成和类库引用。但代码生成和类库引用，都只解决了逻辑的分解能力，没有提供集成能力，所以一般情况下需要提供框架集成，尤其代码生成需要在系统的最外层，避免集成带来的问题。
    代码生成也没有那么坏，关键在于生成什么，如果是生成结构性的代码，由于往往不是最终的产物，就存在同步维护问题；同时这种代码是大都可以用template完成的。
    但如果生成的是功能性代码，这类代码是最终执行代码，那么通常就把用于设计的代码看作是最终产物，最明显的例子是DSL。
   

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。