博客园_Anders小明的Blog

关于架构的思考

2011-07-01T08:12:00Z

作者： Anders小明

一、 架构是什么

通常关于架构的第一个问题是架构是什么，很自然也很正常，本文也不能免俗。然而关于这个问题却没有一致性答案，同时也要注意到不同应用的架构实质上存在不同差异性。

(一) 架构的定义

架构，虽然人们一直在讨论它，甚至于每天都在同其工作，然而这个词并没有一个被业界广泛认可的定义。

大致而言，架构的定义分为三类：

类别	定义
结构论	牛津高阶词典: The design an structure of a computer system
	韦氏大辞典: The way in which the parts of a computer are organized
	IEEE: The fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment,and the principle guiding its design and evolution
关键论	架构是系统中最关键的20%，关注在系统非功能性需求
文化论	架构是关于系统一些的决策

(二) 架构的分类

架构由于应用的不同而存在不同。大体而言，我们可以将当前的应用分为如下四种：互联网应用、企业应用、桌面/移动应用和游戏。

需要一提的是，虽然几种应用的存在一定的模糊性，某种技术为多种应用所共用，例如很多的企业应用基于互联网技术SaaS，以及移动设备的支持。但依然存在很大的不同。

特别的，对于企业架构，大体存在如下几种流派：

1. TOGAF， OpenGroup组织提出，围绕业务、应用、技术和数据四个方面描述架构；

2. DoDAF/MoDAF，美国和英国国防部提出的架构方案；

3. Zachman Framework，根据不同角色的5W1H来审视架构；

4. 4+1视图，由Philippe Kruchten提出，并被RUP采纳；

(三) 架构的关键非功能指标

通常来讲，架构所关注的非功能需求可以分为三个角度5个特性，如下：

角度	特性	说明
运营角度	伸缩性	主要为水平扩展能力
运营角度	可靠性	包括容错性、可用性和安全性等；
开发角度	维护性
开发角度	扩展性	能否快速应对业务的变化
应用角度	易用性	对最终用户是否友好

非功能性指标当然不止这些，如下是一些参考：

1. ISO 9126提出的质量特性：

2. 或者通过如下三个视图来进行：

i. 业务视角

Time To Market、Cost and Benefits、Projected life time、Targeted Market、Integration with Legacy System、Roll back Schedule

ii. 最终用户视角

Performance、Availability、Usability、Security

iii. 开发视角

Maintainability、Portability、Reusability、Testability

3. 也可以通过诸如：简洁性、清晰和一致性等指标。

不同类型的应用关注点会有很大不同，例如：互联网应用由于面临大量的最终用户，会特别关注于伸缩性、可靠性和易用性，这并不是说互联网应用不关注维护性和扩展性，只是会更加强调另外三个特性；而企业应用由于关注于数据、流程以及业务的适应性，会更多得强调维护性和扩展性，而其他特性如易用性相对弱化（面对内部用户，强制使用），伸缩性（内部用户访问量少，大部分情况下通过现有硬件即可支持）。同时，企业应用对数据一致性和准确性要求非常高，而互联网应用相对可以容忍一定的不一致性和错误。因此，一个企业应用的架构师可能无法设计互联网应用的架构。

二、 架构有什么

架构有什么，通常会来一张或者一堆好看的图画。既然本篇不讨论具体应用，故而也拿不出啥图了，也不想讨论这些。因为不同的应用存在的差异，非本文所能涵盖。这里就想讨论下形形色色架构图的背后的内容，以及隶属架构但未在架构图表达的内容。

《易经·系辞》有云：“形而上者谓之道，形而下者谓之器”，将架构分为“形而上”和“形而下”两个部分，如下图：

(一) 形而上

形而上体系中，除去前置内容，分为文化和支撑两大块。

其中，文化部分里最重要的就是原则和方法论，例如：关注点分离原则（SoC），面向对象分析设计和领域驱动设计等等。在此之下，就是架构模式和算法，常见架构模式为：结构化（分层、管道流、黑板）、分布式（代理和管道流）、交互系统（MVC和PAC）和适配系统（微内核、元数据）。当然还有更低一层次的设计模式（创建、结构和行为）。

(二) 形而下

形而下分为三个部分，运行时、工具和文档。

其中，运行时的内容按照重要性依次为：语言、平台/中间件、框架、类库和工具，具体在企业应用中就是：Java/C#、Windows/Linux、Application Server/Database、Spring/Hibernate等等。

如果说运行时决定最终能力，则工具就事关效率。工具中最常见的是集成开发环境了，此外还有配置、部署和测试工具。

文档部分是另一个重要的内容，应包括：视图（从不同角色出发，可以参考4+1），范例和各种指导参考文档。

三、 架构如何设计

如果把“形而下”当成架构设计的产出，那么架构设计往前追溯，就有输入和加工过程。

(一) 架构的输入

架构的输入包括三个部分：目标、需求和相应约束。其中：目标是大方向内容，需求关注在细节，而约束对目标的达成提供了限定。特别的，关注在非功能性指标上。

(二) 架构的设计过程

架构的设计从需求分析开始，结合参考模型或者已有架构体系，结合原则、方法论等等作料。其主要活动有：技术选型、脚手架/框架/平台搭建等等。

关于具体过程的描述，可见《如何定义和建立架构》。

四、 架构如何评估

架构设计出后一个重要的工作是对架构（形而下部分）进行评估，进行架构评估的必要性在：使得架构设计工作形成闭环，确保当前架构是合适和正确的。

大体上，架构评估有三种方法：

· ATAM: Architecture Tradeoff Analysis Method

· SAAM: Software Architecture Analysis Method

· ARID: Active Reviews for Intermediate Designs

在进行架构评估工作时，首先要确定架构评估的参与人，包括相应的干系人和独立的评估队伍；然后是确定评估的时机：早期（在架构设计期间就参与评估）和晚期（传动的，在架构设计完成后）。

评估内容包括如下：

1. 首先是要满足其输入：目标、需求和约束；

2. 各项的非功能性指标；

五、小结

以如下思维导图作为本文的小结：

本文链接

如何定义和建立架构

2010-10-31T03:41:00Z

作者： Anders小明

在牛津高阶词典（第7版）中，架构（architecture）一词的解释是：the design an structure of a computer system。这个解释实际上已经描述了架构的本质：架构是关于怎么做（构成系统）的，而非做什么的。更进一步，架构是由人来设计实施，因此架构实际上是一个文化（culture）——我们怎么认识或理解系统/产品的，并且我们准备怎么做，在做的过程中我们认为什么是好的，什么是好的等等。

任何系统都有架构，无论多小的系统都有。区别在于其架构是否是经过明确设计并表达。一个合理的架构无疑是经过精心设计和维护的，而进行架构设计，或者说定义/建立一个架构可以分为如下几个步骤。

特别的，本文针对于企业应用架构，其他应用未必适用。

基线准备

如果建立第一版架构（即从零开始）可以跳过此步，但对于建立第n版（n>=2）架构，则需要进行基线准备。通常从上一个架构设计开始，去除不在必要的内容作为基线。

非功能性需求的收集、分析和细化

这步骤非常关键，本质上架构关注的是系统的非功能性需求，虽然不是系统的全部，但无疑是最重要的20%，而这也是不同公司/产品的架构差异性的根源。

一个完整的非功能性需求列表不仅仅来自业务部门（系统客户），还需要包括开发/研发管理层以及开发团队。实践中可以如下检查列表来帮助收集：

l 目标应用，企业应用和互联网应用就不太相同

l 目标环境，系统部署的硬件环境、网络环境等，更有云计算环境和传统服务器环境的差异。

l 常见技术指标

n 稳定性/可用性，主要是MTBF和MTBR指标要求

n 性能，如Web应用下单次操作1/5/10原则，相关并发压力要求等

n 容量，主要是数据容量，此外有时还要考虑内存的限制

n 实时性，涉及到数据同步/复制/消息传播/异步操作

n 易用性，这个指标不容易衡量

l 系统/项目/产品自身，来自客户

l 管理指标，主要来自管理层

n 成熟度/培训招聘成本

n 产品化/定制化

n 组件化

n 领域化

n 标准性

n 平台化/小型中间件

n 集成性/兼容/迁移能力

涉及遗留系统，关于兼容需要明确的兼容方式和兼容模式。兼容方式包括：语义兼容/源代码（语言级/API级）兼容/运行时兼容（运行库/二进制）；兼容模式：向前兼容/向后兼容。

n 1.4.6 容错性

包括速错能力和消除易错机制（error-prone mechanism）

n 1.4.7 升级性

以上列表略显草根性，实际过程中也可以从架构评估角度反向进行非功能性需求收集，可以参考《Attribute Based Architectural Evaluation》。

一次性完整地收集非功能性需求并不是件容易的事，因此在架构发布后也要不停的进行改进。

架构定义

完成非功能性需求并明确后，就可以进行架构定义了。架构定义可以分为三个部分：设计、选型以及构建和评估。

架构设计

这个阶段相对务虚，但却是整个架构定义的基础，决定了所有的后续工作。主要包括如下三个工作内容：

l 确定架构手段，包括架构的原则、规范、模式、工具、框架/平台和语言，以及这些手段的适用范围，哪些问题应用工具来解决，而另一些问题采用哪个框架/平台完成，还有一些通过原则或规范处理。

l 确定组织分工和流程，不同的工作通过组织内不同角色完成。

l 确定结构化范围，区分系统内和系统外，并非所有非功能性需求都是通过系统的手段解决，适当采用系统外手段甚至更简单和准确。

技术选型/预研

纸面上的架构其约束性和可操作性非常低，为了让架构从三万英尺的高空落地有两种办法：流程和平台。其中，流程是由组件分工完成，而平台构建通常不会从零开始，实践中会尽可能利用已有成果：商业产品和开源产品。因此技术选型以及预研工作则显得非常重要。

进行技术选型需要注意两个关键点：

u 评估单项技术的有用性（技术功能）和可用性（非功能性需求，即使用成本）

有用性是指相应的技术功能点是否解决架构所面临的功能性和非功能性需求；

可用性是指是否满足整体的非功能性需求，如性能、容量和稳定性。以及管理层关注指标（使用成本），如技术成熟度、标准性、培训招聘成本以及产品的生命周期，以及License费用等。

u 保持全局视角

关注全局，木桶理论的再次应用，避免某项技术存在的缺陷影响整体。

主要的选型内容如下：

l 语言，不同语言所能提供的开发能力是不同。而且开发语言直接影响到后续技术的选型以及人员的招聘。

l 框架/平台，提供运行环境和集成环境。

l 工具，古话说：磨刀不误砍柴工。但要注意避免工具中心论，正确认识工具的用于——工具是帮助我们解决一些脏活累活的，除此外无它。在整个架构中，工具的作用是大大低于语言和框架/平台。

除去技术选型外，对于一些不确定的内容，还需开展预研工作，验证其可行性或者进行性能测试。

架构构建和评估

如前所述为了使架构落地，在技术选型后完成后进行架构构建，包括了定制化设计和开发，并进行质量保证。

架构构建的结果通常分为三个层次：

l 集成环境，提供一个开发的脚手架，这个是最低层次。

l 编程模型，提供一个统一的编程模型，包含了自定义框架和类库，并对底层技术提供了一定封装和隐藏。当前的趋势是：提供一个POJO一致性的编程模型。

l 运行平台，提供了一个运行平台，（勉强）可以算做一个中间件产品。

架构构建过程中应注意如下内容：

l 应用区分平台系统和应用开发接口

应用开发接口是给后续产品开发使用，接口一旦设计发布应当保持问题性和兼容性；而平台系统对后续系统开发不可见，避免兼容设计成本，有利后续升级和变化。

l 简单的API，强大的功能，类似于高级语言

l 可以扩展的SPI，另一种形式的API

l 消除易错机制（error-prone mechanism），避免当错误使用后的修正成本太高

l 适应变化和二八原则，避免在需求变化时后调整的成本过高

l 隔离具体技术，保持未来的迁移性和可升级性

l 提供调用接口和模型应具备一定抽象性

l 分离关注点，纵向的层次化抽象，以及横向的模块与切面

l 提供申明式定义（如XML），由反向解析映射到具体技术，关注于做什么而非怎么做。

架构完成构建后，进入架构评估。

架构评估是确保架构有效性的重要步骤，需要针对所收集到的非功能性需求——工作上形成一个闭环，确保工作的有效性——因为架构涉及系统中最重要的20%，应该尽早验证，而不是简单地希望一切都好。

架构评估包括两个工作：进行验证和协助。

可以根据非功能性需求列表来制定验证点，这里列举下主要的验证点：

l 技术点验证

l 性能压力验证

l 稳定性验证

更正规的评估方法可以参考《Attribute Based Architectural Evaluation》。

协助是架构评估的另一项工作。架构不是几个人关在一个房间里整出来的与世隔绝的东西。需要项目/系统/产品的等相关利益者理解它。这项工作不应是发布几份文档宣称架构如此如此（见后续《架构发布》），它应当在架构评估时进行（虽然可以在架构构建时进行，但是由于此时架构并未成形，此时的效果有限）。

架构发布

当架构构建完成并通过评估，架构就可以正式发布了。

框架/平台和工具

毫无疑问，框架/平台和工具是架构发布主要内容之一。

文档

除去框架框架/平台和工具，还有其他重要的内容需要发布，文档无疑必须的。但文档也存在尴尬的情况，已知的工程实践中已经发布了太多无用的文档、过期的文档。

应努力保证所发布文档的必要性和有效性，建议文档如下：

l 架构介绍，可以参考RUP4+1视图，部署视图、运行视图、开发视图等

l 快速入门

l 开发指南

l 服务配置和使用介绍

示例代码

完整可用的代码，运行脚本、注释。完整丰富的示例代码在很多时候比文档更直接，尤其在展示细节问题上。

培训和指导

很多时候，培训和指导被忽略了。相对于文档和示例代码，培训和指导更有互动性，可以更深入讨论，并可以深入到架构设计背后的故事。

架构改进

如前所述，通常无法一次收集完整地非功能性需求；而随着时间发展，更新更细节的非功能性需求会不断的涌现和被发现；还有一部分之前已识别但被暂时搁置的非功能性需求开始变得重要。因此架构需要不断发展，而此时的改进通常是以小步快跑的方式进行。

下一个周期

不能期望10年前的架构能够满足今天的需求（它可能依然可以工作）。架构发布后到一定阶段，已经无法通过小的改进满足新的要求，重新进行架构设计成为一个必然。而当前的架构设计可以转为下一次设计的基线。

常见的问题

l 试图创建一个私有的编程模型标准

很少有人这么干，不过有时还遇到这样的做法。通常在封装一些商业或开源产品，美名其曰——隔离实现，这是一个危险的做法，其实质是创建一个私有编程模型标准，如果业界没有纸上标准或实际标准，基于某个产品实现所建立的私有标准无法真正的迁移到别的产品实现；如果有，那就根本不需要建立私有标准。

另有一种封装，其目的是为了简化商业或开源产品，这种封装不打算屏蔽底层的实现——它只是让工作更简单。

如果一定要创建一个编程模型的话，应该是POJO。

l 不那么正确的二八原理

二八原理通常很有效，然而它有缺陷——他是基于统计的，这意味着是事后应对。如果没有已有实践经验，那么在一开始很难做出正确判断。

而一旦做出错误的决策导致的问题，很可能出现“玻璃裂纹”现象——不断的扩散并破坏架构设计——直到玻璃碎掉。

更槽糕的是，很多时候所谓的二八划分，基于的是感觉而非统计。

l 过分关注在技术模型上

虽然架构针对的非功能性需求，关注在技术模型没有问题，但是实际上更应关注的是信息模型。而在多数情况下，信息模型是以层的形式来表示。

这里面最典型的是所谓的N层（n-tier）模型，实际上，N层（n-tier）模型就是一个技术模型，描述的一个分布式系统结构。

而真正的N层（n-layer）设计却被忽视，分层Layer模式才是一个架构模式（见POSA vol1），ISO-7层网络协议是一个典型示例。

本文链接

企业应用下的业务组件开发实践

2010-02-21T06:07:00Z

作者： Anders小明

什么是企业应用下的业务组件

首先，这是一个组件，这意味着它需要在容器里运行，因此不包括任何中间件服务，同时以一定结构（文件结构或者压缩格式）组成，被容器识别；其次，这是一个业务组件，即提供的是应用服务，而非技术服务；第三，这是企业应用，在业务上包括功能和服务（Service，当前最时髦的说法，你可以理解为API），技术上（以J2EE来讲）包括：UI资源（JSF、JSP、JS和CSS等）、应用程序（Java）资源和配置文件、数据库表定义、初始化数据和存储过程。

为什么要企业应用下的业务组件

组件技术从提出到现在已经有20多年了，为什么要提企业应用业务组件？因为现有的组件技术不支持企业应用环境下的组件要求，J2EE的EJB不支持，.NET的DLL也不支持。

如前所述，一个企业应用通常包括了交互界面、应用代码以及数据库结构，而不论是EJB还是DLL只支持应用代码，都不包括交互界面和数据库结构。

如果说EJB不是，那么J2EE的EAR或者WAR是否算是一个组件？答案也不是，EAR或者WAR部署的是一个企业应用，请注意EJB规范中明确说：The Enterprise JavaBeans architecture is a architecture for the development and deployment of component-based (distributed) business applications(EJB 2.x和3.x唯一的区别是2.x有distributed），它们有自己的应用域，彼此相互隔离（简单的看，它们有各自独立的会话管理）。.NET也是有自己的应用域概念。

更进一步，基于应用的部署导致了三个隔离问题：交互（界面）隔离、程序访问隔离和数据隔离（请注意这三个问题分别对应了企业应用业务组件的三个技术内容）。交互隔离导致了企业用户必须访问不同界面，代码访问隔离导致了点对点的集成以及诸如性能、事务和异步处理等各种非功能性问题，而数据隔离导致了数据有效性、一致性等等问题。所有这些都进而导致了维护的问题。

为了解决这些问题，大厂商们都提出了各种解决方案：Portal来解决交互隔离问题，通过ESB来解决代码访问隔离问题，以及通过所谓的信息服务（Information Service）来解决数据隔离问题。

那么OSGi技术或者SCA技术能否满足要求？答案是目前不能，OSGi最初开发的目的就不是为了企业应用，只是这几年开始成熟，并向企业应用方向发展。09年推出的企业版（草案）刚刚提出针对程序访问问题的方案，如远程服务、事务管理等；交互隔离问题上规范并没有提出相应方案，只有Eclipse的Equinox提出了界面的扩展点机制，但这也不能解决B/S环境的问题；而数据隔离问题就没有任何方案。SCA从一开始就是面向企业应用，不过不解决交互隔离和数据隔离问题。

此外，对于行业ISV来说，除企业用户面临的这些种种问题，还面临着其它问题。企业用户毕竟只是面对自己的需求，行业ISV却面临着多个企业用户的需求，面临定制化带来的维护问题，特别是业务和技术的隔离问题（即如何保持构建业务组件的所使用技术的平稳升级）。

组件的容器

既然要企业应用下的业务组件，而现有的组件技术又无法支撑，那么就需要一个新的组件容器了（当然，作为一个普通开发人员，我们无法新建一个公开标准的组件体系，也独立维护一个私有的）。新的组件容器完全使用现有的中间件技术，并加上一些新的内容，包括如下：

组件框架，识别组件，以及组件（文件）结构和各个技术工件。
技术框架，提供业务无关的技术支持，以便于技术的平稳升级切换。
运行容器，采用现有中间件技术，包括Tomcat、应用服务器和数据库服务等；
工具，包括打包以及部署工具等。

关于数据隔离问题，在EIP中提到了各种解决方案，这里采用的共享数据库方式，即各个组件都共用一个数据库，各个组件只提供数据库定义和初时数据（如同EJB/OSGi一样，运行时环境由容器提供）。

组件的关系

组件的关系分为两种：依赖和联动。依赖关系在已有的组件技术上已经广为认知，而联动则是新创造的（肯定不是第一个创建的，只不过不同人有不同的叫法）。

联动和依赖的区别是：如果有组件B和组件A联动，则组件B可以在没有组件A的情况下运行，并提供相应功能。

针对三种不同技术工件（即三个隔离问题）呈现不同特点，如下：

1. UI资源（交互隔离问题），依赖是指UI资源的嵌入、引用和替换，联动是指UI资源的新增。

2. 应用程序（程序访问隔离），依赖是指API/模型依赖，联动是指消息（传统消息和JMS消息）以及SPI实现。其中，无论是依赖或者联动都涉及到相应的非功能性需求，包括：异步、事务控制和服务时限等。

3. 数据库资源（数据隔离），依赖是指外键关联和级联操作，无明显的联动关系。

这里，需要关注应用程序的依赖和联动

1. SPI和API存在业务不匹配问题。

虽然组件A依赖组件B，但是不代表组件B提供的服务完全匹配组件A的要求。有时组件A所需要的数据需要组件B的多个API组成，为了开发方便或者组件A所需要的性能问题，可能会在组件B新写一个接口给组件A使用，注意该接口不是组件B的API，该接口仅适用于组件A。

2. 尽可能的使用SPI集成方式

SPI集成方式是相对于API集成方式，API集成方式就是，组件B直接调用其它组件的API及其模型。SPI集成方式（类似于依赖倒置），组件B定义其所需要的接口及其模型，由组件A或者胶水层代码来实现。

这个点对于行业ISV尤为明显。对于企业用户来说，依赖是明确的，组件A依赖/联动于组件B，但对于行业ISV，则面临着定制化问题，虽然组件A依赖/联动于组件B，但是在某个定制化项目中，由于客户已有系统C，而需要组件A依赖/联动于客户已有系统C。此时采用SPI方式。

在开源世界里采用SPI方式更是广泛。很多框架为了兼容（同一功能）不同实现的类库，都是先定义框架所需接口，并同时提供不同类库的胶水代码。

不论是EJB/OSGi/SCA都没有对SPI集成方式的支持。

3. 依赖和联动的非功能性需求。

事实上，非功能性需求都是在集成时才存在的。以事务管理为例，除了及其少数的例子外，大部分事务只能在处理流程才被决定（注意，EJB在这方面着是定义在API上的，这样的设计是不适应需求的），而组件A的API在用例1中需要被异步调用，而在用例2中需要被同步调用是常见的。即便是OSGi规范，也在这方面没有任何处理。

组件的定制化

定制化问题只针对于行业ISV有效，对于企业用户来说，除非是那种跨国企业在面临不同国度的业务模式、法律监管和会计制度等差异，存在定制化需要，即使如此，ISV和企业用户对于同一问题的解决方式也是不同的。

既然我们已经将原有的应用采用组件化方式开发，那么应用的定制化问题就转化为组件的定制化问题。同样，应用的定制化手段也就转化为组件的定制化手段。

组件框架

罗罗嗦嗦的说了半天，有人就说了：这不就是把UI、Java和数据库三个东东一打包，然后说这就是一个企业应用下的业务组件，有啥新意呢，不就是模块化开发嘛，一直一来大家都是就是这么搞的嘛，何必搞个怪名词来忽悠。

是的，就是把UI、Java和数据库三个东东整合在一起，组件容器说提到的技术框架很多的开发队伍都有一套，运行容器更是有无数开源商业的，打包部署工具更是写了无数。

这确确实实就是我们常说的模块化开发。但是模块化开发不同于组件开发，模块化开发只是在逻辑上做了切分，物理上（开发出的系统代码）通常并没有真正意义上的隔离，一切都只是在文档中。

我们需要一点干货，只有实实在在的组件框架才能组件化开发真正落地的（如同OSGi框架那样）：我们需要一个类似于Equinox的界面扩展框架来支持UI资源的依赖和联动；我们需要一个集成框架来支持应用程序的依赖和联动，解决所面临的种种问题（业务不匹配、SPI集成以及各种非功能性需求）；我们需要一个打包部署工具（类似Spring DM）提供部署UI资源、应用程序和数据库定义资源（Spring DM提供了基于Web资源的部署能力）。

其它问题

对于采用J2EE下B/S环境的组件应用还面临一个问题，即现有Servlet规范只允许一个web.xml，不支持组件各自定义私有的Filter和Servlet，不过这个问题不是很严重，在现有技术框架已经支持一份简单的web.xml，而新的Servlet规范已经允许多个web.xml。

分布式部署以及集群部署问题，这其实不是个问题。基于应用的我们有很多手段和技术，那么基于组件的也一样有办法。

本文链接

浅谈领域驱动设计

2009-05-07T14:27:00Z

简要总结了一下领域驱动设计的需求背景，支持技术，当前不足以及相应的技术分析

浅谈基础平台

2009-05-05T23:57:00Z

简要讨论了基础平台的定义、必要性、评价指标及其构建等5个问题

浅谈企业应用架构（二）

2009-05-05T17:25:00Z

简要讨论了基础平台的定义、必要性、评价指标及其构建等5个问题

浅谈企业应用架构（一）

2009-05-05T15:22:00Z

这是关于企业应用架构的总结，分别从架构的定义和分类、目标和愿景，评价指标、原则和方法论、技术层面以及展示6个部分阐释我所理解的架构。共分为两个部分。第一部分包括架构的定义和分类、目标和愿景，评价指标以及原则和方法论；第二部分包括技术层面以及展示。

技术书籍推荐

2008-03-26T13:57:00Z

dudu发起图书推荐活动，我整理这些年看的书，去除了经济学类的，对技术类书籍做了一些减法，以下是我认为不能再精减的书，特此向大家推荐：

AOSD的实践冲动——Use Case的实现

2008-01-12T13:39:00Z

讨论一下AOSD的实践冲动，以及AOP是所做的工作实质。

业务流程的层次和内容

2008-01-08T14:19:00Z

业务流程的几个层次，及其关注内容