How can you improve Java I/O performance?

How would you improve performance of a Java application?

扬子江 发表于 2006-4-11 15:12:38
 
前言：
公司开发了一个网站，估计最高在线人数是3万，并发人数最多100人。开发的网站是否能否承受这个压力，如何确保网站的负荷没有问题，经过研究决定如下：
（1） 采用负载平衡和集群技术，初步机构采用Apache+Tomcat的机群技术。
（2） 采用压力测试工具，测试压力。工具是Loadrunner。
硬件环境搭建：
为了能够进行压力测试，需要搭建一个环境。刚开始时，测试在公司局域网内进行，但很快发现了一个问题，即一个脚本的压力测试结果每次都不一样，并且差别很大。原来是受公司网络的影响，于是决定搭建一个完全隔离的局域网测试。搭建后的局域网配置如下：
（1） 网络速度：100M
（2） 三台服务器：
负载服务器 ：操作系统windows2003，
Tomcat服务器：操作系统windows2000 Professional
数据库服务器：操作系统windows2000 Professional
三台机器的cpu 2.4 G, 内存 1G。
软件环境搭建：
软件的版本如下：
Apache 版本：2.054，
Tomcat5.0.30,
mysql ：4.1.14.
JDK1.5
压力测试工具：Loadrunner7.8。

负载平衡方案如下：
一台机器（操作系统2003）安装apache，作为负载服务器，并安装tomcat作为一个worker；一个单独安装tomcat，作为第二个worker；剩下的一台单独作为数据库服务器。
Apache和tomcat的负载平衡采用JK1.2.14（没有采用2.0，主要是2.0不再维护了）。
集群方案：
采用Tomcat本身的集群方案。在server.xml配置。
压力测试问题：
压力测试后，发现了一些问题，现一一列出来：
（1） 采用Tocmat集群后，速度变得很慢。因为集群后，要进行session复制，导致速度较慢。Tomcatd的复制，目前不支持application 复制。复制的作用，主要用来容错的，即一台机器有故障后，apache可以把请求自动转发到另外一个机器。在容错和速度的考虑上，我们最终选择速度，去掉 了Tomcat集群。
（2） 操作系统最大并发用户的限制：
为了采用网站的压力，我们开始的时候，仅测试Tomcat的最大负载数。 Tomcat服务器安装的操作系统是windows2000 Professional。当我们用压力测试工具，并发测试时，发现只要超过15个并发用户，会经常出现无法连接服务器的情况。经过研究，发现是操作系统 的问题：windows2000 Professional 支持的并发访问用户有限，默认的好像是15个。于是我们把操作系统全部采用windows2003 server版本。
（3） 数据库连接池的问题：
测 试数据库连接性能时，发现数据库连接速度很慢。每增加一些用户，连接性能就差了很多。我们采用的数据库连接池是DBCP，默认的初始化为50个，应该不会 很慢吧。查询数据库的连接数，发现初始化，只初始化一个连接。并发增加一个用户时，程序就会重新创建一个连接，导致连接很慢。原因就在这里了。如何解决 呢？偶尔在JDK1.4下的Tomcat5.0.30下执行数据库连接压力测试，发现速度很快，程序创建数据库连接的速度也是很快的。看来JDK1.5的 JDBC驱动程序有问题。于是我们修改 JDK的版本为1.4.

（4） C3P0和DBCP
C3P0是Hibernate3.0默认的自带数据库连接池，DBCP是Apache开发的数据库连接池。我们对这两种连接池进行压力测试对比，发现在并发300个用户以下时，DBCP比C3P0平均时间快1秒左右。但在并发400个用户时，两者差不多。

速度上虽然DBCP比C3P0快些，但是有BUG：当DBCP建立的数据库连接，因为某种原因断掉后，DBCP将不会再重新创建新的连接，导致必须重新启动Tomcat才能解决问题。DBCP的BUG使我们决定采用C3P0作为数据库连接池。
调整后的方案：
操作系统Windows2003 server版本
JDK1.4
Tomcat 5.0.30
数据库连接池C3P0
仅采用负载平衡，不采用集群。
软件的配置：
Apache配置：主要配置httpd.conf和新增加的文件workers.properties
Httpd.conf：
#一个连接的最大请求数量
MaxKeepAliveRequests 10000
#NT环境，只能配置这个参数来提供性能
<IfModule mpm_winnt.c>
#每个进程的线程数，最大1920。NT只启动父子两个进程，不能设置启动多个进程
ThreadsPerChild 1900
每个子进程能够处理的最大请求数
MaxRequestsPerChild 10000
</IfModule>

# 加载mod_jk
#
LoadModule jk_module modules/mod_jk.so
#
# 配置mod_jk
#
JkWorkersFile conf/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel info
#请求分发，对jsp文件，.do等动态请求交由tomcat处理
DocumentRoot "C:/Apache/htdocs"
JkMount /*.jsp loadbalancer
JkMount /*.do loadbalancer
JkMount /servlet/* loadbalancer
#关掉主机Lookup，如果为on，很影响性能，可以有10多秒钟的延迟。
HostnameLookups Off
#缓存配置
LoadModule cache_module modules/mod_cache.so
LoadModule disk_cache_module modules/mod_disk_cache.so
LoadModule mem_cache_module modules/mod_mem_cache.so

<IfModule mod_cache.c>
CacheForceCompletion 100
CacheDefaultExpire 3600
CacheMaxExpire 86400
CacheLastModifiedFactor 0.1

<IfModule mod_disk_cache.c>
CacheEnable disk /
CacheRoot c:/cacheroot
CacheSize 327680
CacheDirLength 4
CacheDirLevels 5
CacheGcInterval 4
</IfModule>
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 8192
MCacheMaxObjectCount 10000
MCacheMinObjectSize 1
MCacheMaxObjectSize 51200
</IfModule>
</IfModule>
worker. Properties文件
#
# workers.properties ，可以参考
http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html
# In Unix, we use forward slashes:
ps=

# list the workers by name

worker.list=tomcat1, tomcat2, loadbalancer

# ------------------------
# First tomcat server
# ------------------------
worker.tomcat1.port=8009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13

# Specify the size of the open connection cache.
#worker.tomcat1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
# ----> lbfactor must be > 0
# ----> Low lbfactor means less work done by the worker.
worker.tomcat1.lbfactor=900

# ------------------------
# Second tomcat server
# ------------------------
worker.tomcat1.port=8009
worker.tomcat1.host=202.88.8.101
worker.tomcat1.type=ajp13

# Specify the size of the open connection cache.
#worker.tomcat1.cachesize

#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
# ----> lbfactor must be > 0
# ----> Low lbfactor means less work done by the worker.
worker.tomcat1.lbfactor=2000

# ------------------------
# Load Balancer worker
# ------------------------

#
# The loadbalancer (type lb) worker performs weighted round-robin
# load balancing with sticky sessions.
# Note:
# ----> If a worker dies, the load balancer will check its state
# once in a while. Until then all work is redirected to peer
# worker.
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=tomcat1,tomcat2

#
# END workers.properties
#

Tomcat1配置:
<!--配置server.xml
去掉8080端口，即注释掉如下代码：-->
<Connector
port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />

<!--配置8009端口如下：-->
<Connector port="8009"
maxThreads="500" minSpareThreads="400" maxSpareThreads="450"
enableLookups="false" redirectPort="8443" debug="0"
protocol="AJP/1.3" />
<!--配置引擎-->
<Engine name="Catalina" defaultHost="localhost" debug="0" jvmRoute="tomcat1">

启动内存配置,开发configure tomcat程序即可配置：
Initial memory pool: 200 M
Maxinum memory pool:300M
Tomcat2配置：
配置和tomcat1差不多，需要改动的地方如下：
<!--配置引擎-->
<Engine name="Catalina" defaultHost="localhost" debug="0" jvmRoute="tomcat2">

启动内存配置,开发configure tomcat程序即可配置：
Initial memory pool: 512 M
Maxinum memory pool:768M
Mysql配置：
Server类型：Dedicated MySQL Server Machine
Database usage:Transational Database Only
并发连接数量：Online Transaction Processing(OLTP)
字符集：UTF8
数据库连接池的配置：
我们采用的是spring 框架，配置如下：
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
<prop key="hibernate.connection.driver_class">com.mysql.jdbc.Driver</prop>
<prop key="hibernate.connection.url">jdbc:mysql://202.88.1.103/db</prop>
<prop key="hibernate.connection.username">sa</prop>
<prop key="hibernate.connection.password"></prop>

<prop key="hibernate.show_sql">false</prop>
<prop key="hibernate.use_sql_comments">false</prop>

<prop key="hibernate.cglib.use_reflection_optimizer">true</prop>
<prop key="hibernate.max_fetch_depth">2</prop>

<prop key="hibernate.c3p0.max_size">200</prop>
<prop key="hibernate.c3p0.min_size">5</prop>
<prop key="hibernate.c3p0.timeout">12000</prop>
<prop key="hibernate.c3p0.max_statements">50</prop>
<prop key="hibernate.c3p0.acquire_increment">1</prop>
</props>
</property>
其他的没有额外配置。
LoadRunner 常见问题：
（1）sofeware caused connction：这种情况，一般是脚本有问题，或者loadrunner有问题。解决方法：重新启动机器，或者重新录制脚本，估计是loadrunner的bug。
（2）cannot connect to server:无法连接到服务器。这种情况是服务器的配置有问题，服务器无法承受过多的并发连接了。需要优化服务器的配置，
如操作系统采用windows 2003 server，
优化tomcat配置：maxThreads="500" minSpareThreads="400" maxSpareThreads="450"。但是tomcat 最多支持500个并发访问
优化apache配置：
ThreadsPerChild 1900
MaxRequestsPerChild 10000
其他的错误如：
Action.c(10): Error -27791: Server has shut down the connection prematurely
HTTP Status-Code=503 (Service Temporarily Unavailable)
一般都是由于服务器配置不够好引起的，按照问题（2）处理，如果仍旧不行，需要优化硬件和调整程序了。
Apache问题：
（1） File does not exist: C:/Apache/htdocs/favicon.ico：
这个问题是apache，htdocs目录没有favicon.ico文件引起的，该文件是网站的图标，仅在firefox,myIE等浏览器出现。
（2） 图片无法显示：
配置apache后，却无法显示图片。
解决方法：把程序的图片，按照程序结构copy到apache的htdocs目录下。
（3） 无法处理请求：
当我们输入 ***.do 命令后，apache确返回错误信息，而连接tomcat却没有问题。原因是没有把.do命令转发给tomcat处理。解决方法如下：
在apache配置文件中配置如下内容：
DocumentRoot "C:/Apache/htdocs"
JkMount /*.jsp loadbalancer
JkMount /*.do loadbalancer

总结：
网站的压力测试，涉及的知识面挺广的，不仅要熟悉压力测试工具，还要知道如何配置和优化应用服务器和数据库，并且需要知道如何优化网络、操作系统、硬件系统。
测 试中不仅要善于发现问题，要知道如何解决。最重要的一点，要有良好的测试方法。刚开始测试时，可以从最简单的测试脚本入手，不需要太复杂的脚本，这样便于 发现问题。如我们刚开始时，就从一个简单的下载登陆界面的脚本入手，测试一个tomcat的压力负载。一个简单的获取登陆的脚本，帮助我们优化了 tomcat的配置；后来再测试数据库连接，也是一个简单的数据库连接脚本，帮助我们优化了数据库连接池；然后利用这些简单的脚本，测试apache的负 载平衡，优化了apache配置。最后运行复杂的脚本，模拟多种角色的用户在不同时间下的处理，以测试网站压力负载。
 

DBCP 使用apache的对象池ObjectPool作为连接池的实现，在构造GenericObjectPool时，会生成一个内嵌类Evictor，实现自 Runnable接口。如果_timeBetweenEvictionRunsMillis大于0，每过 _timeBetweenEvictionRunsMillis毫秒Evictor会调用evict()方法，检查对象的闲置时间是否大于 _minEvictableIdleTimeMillis毫秒（_minEvictableIdleTimeMillis小于等于0时则忽略，默认为30 分钟），是则销毁此对象，否则就激活并校验对象，然后调用ensureMinIdle方法检查确保池中对象个数不小于_minIdle。在调用 returnObject方法把对象放回对象池，首先检查该对象是否有效，然后调用PoolableObjectFactory 的passivateObject方法使对象处于非活动状态。再检查对象池中对象个数是否小于_maxIdle，是则可以把此对象放回对象池，否则销毁此 对象

板桥里人 http://www.jdon.com 2006/8/21

　　当Java世界提供的可选择性框架平台越来越多时，我们可能被平台架构所深深困扰，而无暇顾及软件的真正核心：业务建模，其实，业务领域建模同样是一个比平台架构更复杂，更需要学习的新的领域。

相反，在实践中，我们技术人员在经过冗长的平台架构学习和实践后，就匆忙开始项目开发，这时是什么指导他们进行软件业务实现呢？大部分可能是依赖数据库 建模，甚至是复杂冗长的数据库存储过程设计，这些已经开始走向面向对象分析设计的反方向，走上了一条错误的软件开发方向，最终开发出缓慢的、经常当机的 Java企业系统。

　　如果你没有恰当的OO设计思想，Java就会用性能惩罚你，这可能是Java世界的一个潜规则。

　　那么，一个正确的OOA/OOD/OOP步骤是什么呢？目前围绕模型驱动设计(MDD)的设计思想成为主流思想，MDA更是在MDD基础上提升和升华。下面让我们首先了解，如何使用领域驱动设计思想来分析设计一个软件系统。

　　当我们不再对一个新系统进行数据库提炼时，取而代之的时面向对象的模型提炼。我们必须大刀阔斧地对业务领域进行细分，将一个复杂的业务领域划分为多个小的子领域，同时还必须分清重点和次要部分，抓住核心领域概念，实现重点突破。

核心领域模型

　　精简模型，找出核心领域，将业务需求中最有价值的概念体现出来，让核心变精要，这实际就是一个使复杂问题变简单的过程，也是对我们软件设计人员真正能力的考验。

　　核心领域模型不是轻易能够发现，特别是他处于一个纷乱复杂的众多领域模型结构中时，核心模型通常是我们某个子领域关注的重点，例如订单模型是订单管理领域的核心；消息模型是论坛或消息领域系统的核心。

目前，分析领域有很多模式来帮助我们来提炼核心模型，例如四色原型、Martin Fowler 的分析模式等，例如MF的"分析模式"(Analysis Patterns)中的记帐模型就是不仅仅用来记录账目数值，而且可以记录和控制账目的每一次修改。而四色原型则是一种高于分析模式的一种原型基本模式， 下面是本人根据四色原型提炼的核心领域模型概念。

　　一般情况下，在企业应用中，核心模型总是在其周围围绕一些所谓的“卫星”，这实际上也是来自四色原型的一个推论，核心模型和其“卫星”的类图如下：

根据Eric Evans在其“领域驱动设计”一书中定义，领域模型划分为实体和值对象两种，实体模型是指业务领域中具有独立属性的对象；而值对象则可能是一种 Description或状态或规则。只要有实体对象，就可能存在实体的状态，状态跟踪有时成为一个业务领域使用计算机软件的首要跟踪，但是，数据库不是 对象状态的唯一表达方式，只是一种存储方式(见 状态对象：数据库的替代者 )。

　　图中，实体核心对象大部分可能有一种类型，例如核心模型是产品，那么存在产品目录；核心模型是消息；就存在消息类型；核心模型是信息；总存在信息类别，我们总是使用分类方式来管理业务领域的信息，有时，类别甚至复杂到树形结构。

　　核心实体模型有时会有一个1:N关联的子实体，一般可能表达实体的细节，例如：核心模型是订单，那么存在订单条目这样一个细节，一个订单中可能有多个订单条目；如果核心模型是信息，那么存在该信息的多个回复或评论；这样的关联一般存在多个业务领域中。

模型界面实现

　　原来，我们以为分析设计阶段无需了解实现细节，分析人员只要闷头做分析UML图，而无需顾及如何具体实现，其实这是一个误区。

Eric Evans在其“领域驱动设计”一书中认为：分析人员负责从领域中收集基本概念； 设计则必须指明一组适应编程工具构造的组件，以及这些组件必须能够在目标环境中有效执行。模型驱动设计(Model-Driven Design)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。因此，对于核心模型必须掌握了解其实现细节。

从另外一个方面来说，中国的客户总是从界面设计来表达他们的意图（如果中国客户能够使用Use Case等UML图来表达他们概念真是不可想象），例如客户会说，我希望有一个界面让我将订单数据输入，然后能够查询符合查询条件的订单。因此，我们的核 心模型至少能够顺利地映射到界面实现，相反，这个客户有这样订单界面要求，但是你没有提供一个与之适应的核心实体模型，界面实现将变得复杂，甚至走很多弯 路，诞生不少DTO垃圾对象。

　　以JdonFramework框架实现为例子，框架提供了围绕 核心模型的新增删除修改查询(CRUD)功能以及批量功能的快速实现，尤其CRUD功能实现前提是必须提炼出核心模型，从而其界面设计流程就能通过配置立 即实现，这样一步到位实现领域模型到界面的过渡，可以将我们设计核心模型和客户要求的界面需求能够做到完整的统一。

　　开源JdonFramework下载包中message案 例实际就是上述核心模型图的一种实现项目，更复杂的项目可以认为是核心模型的重叠和反复使用（从原理上讲，核心模型是四色原型的体现，而四色原型被认为是 大部分企业系统的基本组成元素，见[book][UML][Peter Coad]Java Modeling in Color with UML）。

核心模型的选择

　　实际项目中，会存在多个核心模型的重叠和覆盖使用，主要取决于你的领域关注重点。

例如当客户和我们说要做一个旅游网站时，我们必须充分了解需求，它的软件系统重点是哪些功能。如果当他首先说：我需要一个酒店设备的查询系统，因为他的 客户对酒店设备非常关注，那么我们可能认为酒店设备是这个领域模型的核心；酒店设备。如果他又进行描述：我需要一个界面，客户在输入酒店资料时，选择多个 酒店设备，那么在这样一个关注领域，核心模型实际是酒店，而酒店设备可能成为酒店的一个特征实体属性，甚至是值对象了。

以进销存系统为例子，在采购系统中，采购单是一个核心实体模型，而原材料是一种辅助实体模型；在库存系统中，入出库单是一个核心实体模型，原材料或成 品代表的是一个库存物品概念模型，当需要库存报表查询输出，可以立即计算出来，或将结果缓存起来，缓存起来的结果其实是库存物品对象的状态，可以使用值对 象来实现。

核心模型的精练

当核心模型被定位和确定后，相当于我们抓住领域本质，这时我们可以使用面向对象的概念对模型进行精练细化，实际就是明确对象的属性，确定模型对象的边 界，通过反复重构，结合GoF等设计模式，使得我们得模型准确反映本质，从而实现模型的灵活性设计。所有这些，都是数据表驱动设计所不能实现的。那你还抱 着数据库建模干什么呢？

　　见下章： 模型驱动设计(MDD)之灵活设计(续)

板桥里人 http://www.jdon.com 2006/06/06

软件复用本质是为了快速适应不断变化的需求（adapt to changing needs ），两者目标是一致的，但是当我们过于注重软件复用（如组件复用component reuse又译构件复用）时，千万需要牢记：快速适应不断变化的需求是根本目的，它的重要性要重于组件复用技术本身。本文试图阐述两者概念比较以及时下流 行的组件复用技术概要。

适应需求变化

　　现如今是一个计划赶不上变化的时代，企业竞争力逐渐表现在企业适应变化能力的竞争，谁能更快适应市场的变化，谁就能够在竞争中胜出，这种快速适应能力如果靠“人民战争”无疑是不现实的，软件可以帮助我们来适应这种快速变化。

谈到这里，稍微再说明一下国人软件教育的误区，不错，软件曾经是科学计算的工具，因此，我们非常注重软件的算法和数据结构，甚至将之作为数学的衍生物， 但是，现如今已经成为一种帮助我们快速响应变化的有力工具，如果我们的教育背景中只有算法和数据结构，能够编制出应付快速变化的软件吗？很显然，他们是风 马牛不相及，由此可见国人软件概念和软件教育的落后性，在这样的软件认识背景下，固然设计模式的崇高位置得不到确立，软件设计被抛弃在脑后，编制出的大多 数企业软件系统根本不具备应付变化的能力，程序员拒绝频繁更改程序，甚至借助技术原因阻扰软件的频繁更改，这种软件程序员和软件用户之间的矛盾可以称为 miscommunication， miscommunication是导致软件系统的失败一个重要原因。

国内早就有著名言论：“不上ERP等死；上了ERP找死”，如果你的企业不上ERP，那么你的企业就不能借助软件应付快速的市场等环境变化，那么必然会 被淘汰；但是，如果上了一个不注重“适应需求变化”的ERP软件系统，那就是企业被僵化的ERP软件框死，丧失了使用ERP的根本目的。

　　适应需求变化则成为现代软件系统一个孜孜不倦的追求目标，那么如何实现呢？

　　 原则 ：给予人们可以裁剪他们系统的能力应适应需求变化，建立一个适应需求变化的系统，允许系统在一系列小的、可控制的步骤上进行改变。　　

组件诞生

　　将不变的通用的东西抽象出来，以达到在不同项目中重用复用，将我们有限的精力集中在项目具体变化和特点上。当然这些抽象复用的东西之间彼此必须是松耦合，这样才能根据需求挑选组合。

　　让我们先回顾一下软件的发展史，软件开发的发展史实际是一部我们思维不断抽象拔高的发展过程，这种抽象概念非常类似于建模的思考方式：概要贴切地描述事物，忽视次要的细节。抽象体现在软件开发上就是每个具体项目需要完成的代码行数量越来越少。

　　从1970到1980这段时间，软件开发从机器语言到汇编语言。进而发展到高级语言，甚至一些CASE工具，面向功能编程发展到面向对象编程，功能模块重用细化到类的重用，类的重用是最初是通过设计模式实现的。

进入90年代中期，诞生了基于组件的开发模式（CBD：component based development），CBD将抽象概念带往了一个新的方向，与减少代码数量相反，CBD将功能各个方面细化分离到不同的、相互隔离层中，如表现层、 业务逻辑层、持久层、安全层以及核心层等，并且可以管理这些组件之间的依赖关系，通过这种分离，我们可以提纯细化组件功能，进而产生可以重用的框架，如 Struts框架可以重用在大部分应用系统的表现层中，，Struts+JdonFramework+Hibernate是一个框架组合，代表一种架构设 计，这种架构设计其实可以重用在大部分应用系统，这种重用我称之为架构级别重用。

组件复用

软件组件(Software components)是软件提供业务或技术功能的基本单元或元素，这些单元可以独立地被部署、他们可以自我管理并且被虚拟部署到网络的任何地方，业务组 件（(Business components)执行业务逻辑、遵循一定的业务规则并且管理相应的数据（数据库操作称为manage corporate data）；而技术组件(Technical components)则提供相应的平台以便业务组件可以依赖其上运行，例如权限、组件管理等。

JdonFramework/Spring都属于一种技术组件框架，而我们具体项目的业务层代码如果能够提炼可以复用，则是业务组件； JdonFramework/Spring则都提供了业务组件赖于运行的一些核心底层机制，特别是组件的管理，如组件的创建、组件的获得、组件的资源管 理、组件的消亡等生命周期支持，所以，我们可以在JdonFramework/Spring中加入自己的业务组件，当然，JdonFramework还提 供了Session等状态管理的支持功能，为业务组件提供了更广阔的生命周期支持。

　　组件复用 技术以前是停留在编译前期，也就是说：我们在编程时，导入所需要的其他组件Jar包，然后混同我们的项目编译部署，但是这需要通过专业技术人员实现，很显 然是不能适应原则中第一句：给予人们可以裁剪他们系统的能力应适应需求变化，这里的“人们”应该是指软件最终用户，应该给予用户自己改变系统的能力，也就 是说：需要提供软件系统运行时能够动态改变自身的能力。

　　组件复用技术以前停留在软件编译阶段，现在则更靠前，必须在软件运行阶段，当然对技术要求相当高，需要语言支持RTTI（简单又神秘的Class.forName发挥作用了），这在"Evolution, Architecture, and Metamorphosis"一文中被认为是Metamorphosis，现在由于AOP技术出现，AOP有一种动态Weaving技术，实际就是在软件运行时实现动态拦截，这样给予终端用户更大的改变系统能力，他们基本可以以动态插拔的概念实现多个组件的组合运行。在"AOP vs Decorator"一文中，我把编译阶段的组件组合方式（我更愿意称为静态组合）和运行时组合等两种处理方式，合并称为过滤器模式，如果你希望采取组件可插拔式的复用，就可以使用过滤器模式。

组件可插拔更换

　　为什么说组件的可插拔非常重要？

组件重用目的是为了更好地适应需求变化，但是有了组件重用不代表就快速适应需求变化，因为组件本身也会产生设计错误（提炼得不够抽象或者组件很难以替 代），这就必然导致软件系统得维护成本提高，那么快速适应需求变化的目标也就成为一纸空文。实践证明：组件设计问题已经成为导致软件开发失败的一个主要因 素。

　　组件设计有两个主要风险：组件提纯的纯度和组件的替代方式。提炼的纯度也就是抽象的高度，组件的抽象程度越高，当然可重用范围越广，但是往往我们只有经历多个项目后，才发现自己的组件提炼还欠火候，这实际是组件的提炼过程成本。

组件提练虽然取决于人为设计因素，但是在实现手段上也依赖于组件的替换方式，通过经常反复频繁的微调和更换，才能将组件不断提炼向理想状态靠拢，所以， 必须有一种方便的组件替换方式提供频繁更换支持，我们总不希望更换组件象以前更换汽车发动机火花塞一样，需要拆开汽车，打开发动机那样麻烦吧？

参考PC电脑硬件设计：更新CPU或内存条，只要直接插拔就可以，这些部件和母版都是一种松散的、可插拔的关系，如果软件组件替换是动态的可插拔更加方 便终端用户在软件系统交付后，根据需求改变他们的系统。组件可插拔本质上是这些组件必须是最大化的松耦合，彼此依赖影响非常小，换句话说：如果实现了可插 拔更换，说明你的组件已经实现松耦合了。

　　那就有可能设计一种软件框架：它能够为每个部件提供非常棒的服务访问，软件组件是 松耦合'loosely coupled'，这些组件的大部分通过几行代码就可以实现替换。目前这种方便的实现方式是使用XML进行组件的配置。

JdonFramework/Spring都是这样的一种框架，JdonFramework更进步的是：JF框架本身的组件也是可以替换的，例如你希望 在JF中使用Spring的配置文件，那么你只要做一个Spring配置文件的解析组件，然后替换JF框架原来的XML解析器就可以了。无论 EJB2/EJB3等在这方面要稍逊于Ioc/AOP框架，对于支持EJB3的JBoss 4 这样架构，需要动态更换AOP拦截器还不是很方便，因为JBoss 4本身组件没有象JF那样做到可插拔配置，不过，JBoss 5已经开始走上这条路，使用一个微核心来管理所有的可插拔组件，我曾经在"JBoss 5迎来中间件彻底的可配置时代"一文中提出组件是否方便替换是衡量一个组件框架的重要指标。

　　在最近的TheServerSide文章'Service Access' to the software components中，主要是谈论了表现层组件的替换访问方式，GIF这样图片组件不可以随意控制调整，基本不能复用，但是通过SVG或XUI等支持XML组件动态替换技术的使用，则可以实现显示图形组件的复用。

SOA

　　在软件运行时，给予用户动态插拔式更换组件，达到复用的组件更加适合变化的需求，
这是软件业追求的目标，而SOA(Service Oriented Architecture)则是从另外一种方向
也是在运行时提供用户一种改变系统的能力。

　　SCBA(Services and Components Based Architecture), SCBA是通过减少需求变化带来的传递损耗和时间来实现的，当需求变化时，SOA的服务将支持跟进变化和替换。

SCBA更强调的是一种业务过程重用，而且是跨组织跨多个专业域范围的，例如我以前说的四色图实际是对跨域范围的业务总结，特别是ERP域范围，大多数 企业系统都是由MI等四种原始模型组成的，例如JiveJdon3看上去只是一个论坛系统，实际不只是，它的Message模型可以重用在网站内容系统、 新闻发布系统、电子商务系统、仓库管理系统、资源管理系统等跨域范围中（部分已经实现）。

　　既 然业务过程和IT系统可以跨组织跨域重用，那么类似软件系统的维护和开发就不必再重新开发，JiveJdon3的Message模型重用在新闻发布系统 中，我需要把JiveJdon3的项目拷贝到新闻发布系统中，然后再针对新闻发布系统特点做些裁剪修改，这这种复制业会带来工作量和维护量，而SCBA则 可以解决这个问题，通过运行时single-copy reuse分享各种服务功能。

　　更多SOA重用可参考“Service Component White Paper”一文。

总结

　　本文总结了软件复用的不同层次：设计复用、组件架构复用以及业务模型复用，复用技术 的不断发展正是由于适应变化需求的要求不断提高导致，本人从2002年开始从事复用技术研究，最初从复用层次底层设计模式开始，在国内媒体第一次全面分析了GoF设计模式（其中个别模式当时被天极网转载）， 经过这几年发展，亲身体会复用技术已经进入了一个新的阶段。特写此文作为小结。

板桥里人 http://www.jdon.com 2006/7/10（转载请保留）

2004年著名建模专家Eric Evans发表了他最具影响力的著名书籍：Domain-Driven Design –Tackling Complexity in the Heart of Software（中文译名：领域驱动设计　2006年3月清华出版社译本，或称 Domain Driven-Design architecture [Evans DDD]）。

Martin Fowler作序说；“希望本书是一本非常有影响力的书籍,....... Eric最值得我尊敬的一个方面是他敢于讨论还未取得成功的事情”，其实，时值今年2006年，DDD开发框架已经层出不穷（如RoR、RIFE、 JdonFramework等），我们项目软件包结构都变成了这样：xxx.model;xxx.service，DDD思想已经遍地开花，不能再说不成 功了。

　　DDD是告诉我们如何做好业务层！并以领域驱动设计思想来选择和合适的框架，本文以基于JdonFramework开发的JiveJdon3.0说明DDD方法的实战应用。

　　首先必须认识到：领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道（快速适应需求变化的软件复用）。

　　我们知道软件的产生过程是：分析、设计、编程、测试、部署。过去，分析领域和软件设计是分裂的，分析人员从领域中收集基本概念；而设计必须指明一组能北项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程序出现的问题。 模型驱动设计(Model-Driven Design)抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。

　　单一的领域模型同时满足分析原型和软件设计，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。 建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此，建模专家必须懂设计，会编程。

分层架构

　　最初层次只分为三层：表现层、业务层和持久层；DDD其实告诉我们如何让实现业务层！

　　一位道友曾经请教层次的职责，对服务Service提出疑问。根据Eric的理论，业务层将细分为两个层次：应用层和领域层。它们的定义是：应用层：定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题，保持精练；不包括业务规则或知识，无业务情况的状态； 领域层：负责表示业务概念、业务状态的信息和业务规则，是业务软件核心。

　　层次之间必须清晰分离，每个层都是内聚的，并且只依赖它的下层，为了实现各层的最大解耦，Ioc模式和Ioc容器是目前最好的选择，JdonFramework使用基于PicoContainer的Ioc容器实现了各层的松耦合；

Eric特别指出：那种将业务逻辑交由业务界面处理的快速UI方式是旁门左道。希望象C/S结构那样可视化拖拖图形就完成的软件开发是一种错误的方向， 开发时快速，难于维护和扩展，虽然使用J2EE技术，其实是一种伪多层技术。可惜，有很多国人在疯狂开发这类工具，大有不撞南墙不低头之势，并且疯狂误导 很多非专业人士，可悲可叹！如果对这段言论持不同意见，建议你购买"领域驱动设计"这本译书，见P53页。

领域模型种类

　　传统模型分为两种：实体（Entity）和值对象（Value Object），现在服务（Service）成为第三种模型元素。

　　实体（Entity）定义：通过一系列连续性（continuity）和标识（identity　ID）来定义；个人认为它和分析领域的四色原型中的PPT原型非常类似，可以看成是PPT原型延续。

　　实体必须拥有自己的唯一ID，主键，如果没有一个ID标识，为每个实例加上一个具有唯一性ID，可能是内部使用。 如JiveJdon3.0中jdonframework.xml中模型增删改查CRUD配置定义：

　　其中，forumId是模型com.jdon.jivejdon.model.Forum的主键，唯一ID，每个模型必须有一个专家。

值对象（Value Object）：如果一个对象代表了领域的某种描述性特征，且没有概念性的标识。个人认为它是四色原型中Description原型延续。如果我们只关心 模型中一个元素的属性，那么把这个元素划为值对象。值对象是不可变的，不要给它任何标识，避免实体的维护性，降低设计复杂性。我们不关心值对象是哪个实 例。

　　在JiveJdon3.0中，ForumState是一个值对象，它表示论坛当前最新帖子、论坛的主题数量和帖子数量，它的根对象是Forum，是被内聚嵌入到Forum这个实体模型中的，代码如下：

　　同样ForumThreadState是也是一种值对象，根据Eric的值对象设计，ForumThreadState和ForumState是可以合并成一个对象的，值对象中没有ID等唯一标识。

　　Eric认为：服务Service是描述领域概念最自然的方式，是四色原型的MI原型的延续， 优秀服务3个特征：
1.与领域概念相关的操作行为、但不是实体和值对象中固有的部分。
2.接口根据领域模型中其他元素定义
3.操作是无状态的。

在JiveJdon3中，com.jdon.jivejdon.service.ForumService和Forum实体模型及其值对象 ForumState共同完成领域模型，其中ForumService属于应用服务层；而后两者属于领域层；其他服务 ForumMessageService、AccountService和UploadService等都是此类性质。

领域对象的生命周期Scope

Spring 1.x刚出来时确实忽悠了大家一把，因为他没有领域对象的生命周期支持，直到Spring 2.0才将如new Bean scope，当初那些疯狂捧Spring 1.x 臭脚的所谓高手是不是还是基于数据库驱动的思维，根本没有真正OO模式思维，当今天JBoss Seam、Scopes等框架开始重视对象生命周期支持后，曾经发生在Jdon社区争战硝烟已经过去，成为历史。

　　Eric认为：每个对象独有器生命周期，一个对象在创建以后，可能要经历各种不同的状态，并最终消亡。 对象生命周期由长短：临时对象；常驻内存；有的与其他对象存在复杂的依赖关系；状态变化时必须满足一些不变量的约束条件。 如何管理这些对象提出挑战！处理不好会偏离MDD的方向。

　　在生命周期中维护对象的完整性。避免模型由于管理生命周期的复杂性而陷入困境。有 三个模式来处理： 聚合（Aggregate）：定义清晰的所有权和边界使模型更加紧凑，避免出现盘根错节的对象关系网；工厂（Factory）和组合（Respository）。

　　当一个对象生命周期之始，使用工厂和组合提供了访问和控制模型对象的方法，完善了MDD。 建立聚合的模型，并且把工厂和组合加入设计中来，可以使我们系统地对模型对象进行管理。 聚合圈出一个范伟，在这个范围中，对象无论在哪个生命周期，保持不变性。

在JiveJdon3.0中，值对象ForumState是被聚合在实体模型Forum中，Forum作为ForumState的一个根，由于它们数据 必须保持一致性，不变量(invariant)是指无论何时发生数据变化必须满足一致性规则，由于根控制了访问，就无法绕过它修改内部元素，例如，如果没 有Forum实体对象这个根，就无法去修改对象状态ForumState，ForumState获得是通过Forum的getter方法获得的。

　　ForumState和Forum的分离有可以使修改论坛状态数据（当发一个新帖时，必须更新当前论坛的最新帖子为该新帖），不会影响到Forum其他元素，特别是使用事务锁定时，不必锁住整个对象，见"领域驱动设计"书籍P92。

　　另外，ForumThread和ForumMessage的关联关系必设定成单向的，而不是双向的，因为领域建模中，关联越简单越好。

在JiveJdon3.0中，你可能注意到有一个com.jdon.jivejdon.service.factory.ForumBuilder，所 有实体模型对象的获得都是从这个工厂创建出来的，我曾经徘徊过：这个工厂类是否应该属于持久层，因为JiveJdon3.0持久层没有使用 Hibernate这样O/R Mapping框架，而是直接使用SQL，但是从持久层输出的都是对象，这是必须坚持的一个设计原则（好像是MF的一个什么元数据模式） 。

　　但是，Eric明确告诉我们，领域模型的工厂属于应用层，页就是还是应该处于业务层的，这样好处很多，业务层设计根本无需从Hibernate等持久层框架获得，而是从自己的工厂获得。

组合（Respository）又被翻译成仓储，我认为组合合适，主要用来返回一批对象，查询组合常用来返回批量查询结果，JdonFramework 两个快速开发支持：批量查询其实应该是Respository的实现，实际也是过去Master-details的一种查询实现。

　　以com.jdon.jivejdon.presentation.action.ThreadListAction为例子，其功能是查询论坛Forum下所有主题ForumThread，并分页显示，实现效果按这里，我们在customizeListForm方法中将根Model Forum设置进入，在threadList.jsp中，我们使用struts的标签库logic:iterator来遍历组合对象threadListForm中的ForumThread集合。

失血模型

　　MF（Martin Fowler）曾经提出有名的贫血模型或失血模型，让我们好生迷惑和彷徨，他认为实体模型对象中只有弱行为setter和getter方法，没有真正行为，好像缺少血液的人，不和谐了，不少高手又被忽悠了，大谈贫血模型。

　　其实，Eric已经认为，在DDD中，领域中一些概念不能作为模型中的对象来处理的，如果将这些功能概念强行加给实体对象和值对象，破坏模型中对象的定义，人为添加没有意义的对象。服务是描述领域概念最自然的方式。

　　为了在这些大师之间取得一个平衡，有人将Model的持久化操作（CRUD行为）整入到领域模型中，这是不是违背当初Dao模式初衷，Dao模式其实是桥模式和适配器模式组合（见SUN的J2EE核心模式）。

板桥里人 http://www.jdon.com 2006/9/1（转载请保留）

　　越来越多人开始使用Java，但是他们大多数人没有做好足够的思想准备(没有接受OO思想体系相关培训)，以致不能很好驾驭Java项目，甚至 导致开发后的Java系统性能缓慢甚至经常当机。很多人觉得这是Java复杂导致，其实根本原因在于：我们原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当，存在认识上和方法上的误区。

软件的生命性

　　软件是有生命的，这可能是老调重弹了，但是因为它事关分层架构的原由，反复强调都不过分。

　　一个有生命的软件首先必须有一个灵活可扩展的基础架构，其次才是完整的功能。

目前很多人对软件的焦点还是落在后者：完整的功能，觉得一个软件功能越完整越好，其实关键还是架构的灵活性，就是前者，基础架构好，功能添加只是时间和 工作量问题，但是如果架构不好，功能再完整，也不可能包括未来所有功能，软件是有生命的，在未来成长时，更多功能需要加入，但是因为基础架构不灵活不能方 便加入，死路一条。

正因为普通人对软件存在短视误区，对功能追求高于基础架构，很多吃了亏的老程序员就此离开软件行业，带走宝贵的失败经验，新的盲目的年轻程序员还是使 用老的思维往前冲。其实很多国外免费开源框架如ofbiz compiere和slide也存在这方面陷阱，貌似非常符合胃口，其实类似国内那些几百元的盗版软件，扩展性以及持续发展性严重不足。

　　那么选择现在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基础架构打好了呢？其实还不尽然，关键还是取决于你如何使用这些框架来搭建你的业务系统。

存储过程和复杂SQL语句的陷阱

　　首先谈谈存储过程使用的误区，使用存储过程架构的人以为可以解决性能问题，其实它正是导致性能问题的罪魁祸首之一，打个比喻：如果一个人频临死亡，打一针可以让其延长半年，但是打了这针，其他所有医疗方案就全部失效，请问你会使用这种短视方案吗？

为什么这样说呢？如果存储过程都封装了业务过程，那么运行负载都集中在数据库端，要中间J2EE应用服务器干什么？要中间服务器的分布式计算和集群能力 做什么？只能回到过去集中式数据库主机时代。现在软件都是面向互联网的，不象过去那样局限在一个小局域网，多用户并发访问量都是无法确定和衡量，依靠一台 数据库主机显然是不能够承受这样恶劣的用户访问环境的。（当然搞数据库集群也只是五十步和百步的区别）。

从分层角度来看，现在三层架构：表现层、业务层和持久层，三个层次应该分割明显，职责分明：持久层职责持久化保存业务模型对象，业务层对持久层的调用只是 帮助我们激活曾经委托其保管的对象，所以，不能因为持久层是保管者，我们就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组 合。打个比喻：你在火车站将水果和盘子两个对象委托保管处保管，过了两天来取时，你还要求保管处将水果去皮切成块，放在盘子里，做成水果盘给你，合理吗？

　　上面是谈过分依赖持久层的一个现象，还有一个正好相反现象，持久层散发出来，开始挤占业务层，腐蚀业务层，整个业务层到处看见的是数据表的影子（包括数据表的字段），而不是业务对象。这样程序员应该多看看OO经典PoEAA。PoEAA 认为除了持久层，不应该在其他地方看到数据表或表字段名。

　　当然适量使用存储过程，使用数据库优点也是允许的。按照Evans DDD理论，可以将SQL语句和存储过程作为规则Specification一部分。

Hibernate等ORM问题
现在使用Hibernate人也不少，但是他们发现Hibernate性能缓慢，所以寻求解决方案，其实并不是 Hibernate性能缓慢，而是我们使用方式发生错误：

　　“最近本人正搞一个项目，项目中我们用到了struts1.2+hibernate3, 由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false，所以导致数据一加载很慢，而且查询一条数据更是非常的慢。”

Hibernate是一个基于对象模型持久化的技术，因此，关键是我们需要设计出高质量的对象模型，遵循DDD领域建模原则，减少降低关联，通过分层等 有效办法处理关联。如果采取围绕数据表进行设计编程，加上表之间关系复杂（没有科学方法处理、侦察或减少这些关系），必然导致 系统运行缓慢，其实同样问题也适用于当初对EJB的实体Bean的CMP抱怨上，实体Bean是Domain Model持久化，如果不首先设计Domain Model，而是设计数据表，和持久化工具设计目标背道而驰，能不出问题吗？关于这个问题N多年就在Jdon争论过。

　　这里同样延伸出另外一个问题：数据库设计问题，数据库是否需要在项目开始设计？
如果我们进行数据库设计，那么就产生了一系列问题：当我们使用Hibernate实现持久保存时，必须考虑事先设计好的数据库表结构以及他们的关系如何和 业务对象实现映射，这实际上是非常难实现的，这也是很多人觉得使用ORM框架棘手根本原因所在。

　　当然，也有脑力相当发达的人可以 实现，但是这种围绕数据库实现映射的结果必然扭曲业务对象，这类似于两个板块（数据表和业务对象）相撞，必然产生地震，地震的结果是两败俱伤， 软的一方吃亏，业务对象是代码，相对于不容易变更的数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO, DTO满天飞，性能和维护问题随之而来。

　　领域建模解决了上述众多不协调问题，特别是ORM痛苦使用问题，关于ORM/Hibernate使用还是那句老话：如果你不掌握领域建模方法，那么就不要用Hibernate，对于这个层次的你：也许No ORM 更是一个简单之道： No ORM: The simplest solution
http://www.theserverside.com/blogs/thread.tss?thread_id=41715

Spring分层矛盾问题
Spring是以挑战EJB面貌出现，其本身拥有的强大组件定制功能是优点，但是存在实战的一些问题，Spring作为业务层框架，不支持业务层Session 功能。

　　具体举例如下：当我们实现购物车之类业务功能时，需要将购物场合保存到Session中，由于业务层没有方便的Session支持，我们只得将购物车保存到 HttpSession，而HttpSession只有通过HttpRequest才能获得，再因为在Spring业务层容器中是无法访问到HttpRequest这个对象的，所以， 最后我们只能将“购物车保存到HttpSession”这个功能放在表现层中实现，而这个功能明显应该属于业务层功能，这就导致我们的Java项目层次混乱，维护性差。 违背了使用Spring和分层架构最初目的。

　　相关案例：请教一个在完整提交前临时保存的问题:
http://www.jdon.com/jive/article.jsp?forum=46&thread=28429

领域驱动设计DDD
现在回到我们讨论的重点上来，分层架构是我们使用Java的根本原因之一，域建模专家Eric Evans在他的“Domain Model Design”一书中开篇首先强调的是分层架构，整个DDD理论实际是告诉我们如何使用模型对象oo技术和分层架构来设计实现一个Java项目。

我们现在很多人知道Java项目基本有三层：表现层　业务层和持久层，当我们执著于讨论各层框架如何选择之时，实际上我们真正的项目开发工作还没有开 始， 就是我们选定了某种框架的组合（如Struts+Spring+Hibernate或Struts+EJB或Struts+ JdonFramework），我们还没有意识到业务层工作还需要大量工作，DDD提供了在业务层中再划分新的层次思想，如领域层和服务层，甚至再细分为 作业层、能力层、策略层等等。通过层次细化方式达到复杂软件的松耦合。DDD提供了如何细分层次的方式

　　当我们将精力花费在架构技术层面的讨论和研究上时，我们可能忘记以何种依据选择这些架构技术？选择标准是什么？领域驱动设计DDD 回答了这样的问题，DDD会告诉你如果一个框架不能协助你实现分层架构，那就抛弃它，同时，DDD也指出选择框架的考虑目的，使得你不会 人云亦云，陷入复杂的技术细节迷雾中，迷失了架构选择的根本方向。

　　现在也有些人误以为DDD是一种新的理论，其实DDD和设计模式一样，不是一种新的理论，而是实战经验的总结，它将前人 使用面向模型设计的方法经验提炼出来，供后来者学习，以便迅速找到驾驭我们软件项目的根本之道。

　　现在Evans　DDD概念很火，因为它将著名的PoEAA进行了具化，实现了PoEAA可操作性，这也是MF大力推崇的原因。最近(8月8日)一位老外博客上用微软的.NET架构和Evans DDD比较的文章：http://weblogs.asp.net/pgielens/archive/2006/08/08/Organizing-Domain-Logic.aspx，这篇文章比较了微软的三层服务应用架构[Microsoft TLSA]和Evans DDD的架构， 使用Microsoft .NET Pet Shop 4为例子，解释两个目标的区别，并且表明
微软是如何在案例中更好地实现支持后者。这篇文章帮助哪些.NET平台上有域设计知识的人实现更好地提高。

板桥里人 http://www.jdon.com 2006/12/6（转载请保留）

多变且复杂的需求

　　如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个：使得软件更加僵化；或者程序员更加 劳累。

　　需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的专业知识，例如数学、管理、财务或 电子商务等等，每个特定案例需求又有其特别复杂之处，几乎没有人能够第一次接触就可以深入掌握这些专业领域的 需求本质，就是专门的建模专家也不例外。

　　既然需求是多变而且复杂的，所以，就不能使用“堵”式方法对其进行控制和管理，只能顺势而为，通过灵活多变的 以及迭代反复的方式逐步抓住需求，并且作为需求的实现软件系统必须能够迅速应对需求变化，需求变化有多快，软件 变化就有多快。

　　因此，对于多变的需求，我们的解决之道是：引入灵活多变的架构，面向对象OO架构正是应对多变需求而生，强调软件的可维护性 和拓展性，OO可能不是最好方式，但是目前是最合适的；对于复杂的需求，我们的解决之道是：委派专门的建模专家跟踪理解需求， 在需求和需求实现之间搭建桥梁，项目方法上采取多次迭代的敏捷软件开发方式，逐步了解学习掌握需求。

　　在这里稍微说明一下，很多人总是将软件和数学、管理、财务混为一谈，其实软件本身就是一门独立的专业，是为 数学、管理。财务等专业领域服务的，不能期望软件人员也是其他领域专业人员，可是在中国现实中，很多人总是 无法分辨，例如某局长将整个机关考核信息化的任务交给电脑中心，这就是将考核管理专业和软件专业混同的例子， 在考核管理和软件之间需要一个领域建模专家，由他来理解或者设计考核管理体系，然后通过模型，表达成 软件人员能够看懂的符号，软件人员通过模型了解领域。

　　曾经有需求专家呼吁：最好将需求给所有软件人员都了解，需求专家和一般软件人员一起工作，这些想法的本质是 好的，但是不可能实现的，不可能每个软件人员不但了解软件架构和OO思想；还能够掌握另外一个专业领域的艰深知识， 所以，现在我们提出：将领域专家建立的统一领域模型让所有软件人员都了解，让一般软件人员围绕领域模型工作，这样 的方式才切实可行。

需求分析方法演变

　　历史上，对需求分析方法可以说经过三个阶段：

第一阶段：围绕数据库的驱动的分析设计，新软件项目总是从设计数据库及其字段开始。这个阶段特征就是围绕数据库编程，典型的是 DBase/Foxpro，以及后来的Delphi/VB技术。

这种围绕数据库分析设计的缺点非常明显：首先，不能迅速有效全面认识反映需求，世界不只是由简单的关系数据组成，而且 使用关系数据来反映现实需求，不符合人类自然思维（OO才是），是一种扭曲的分析方法，特别对于初学者，他们接受数据库分析方法的难度反而可能会大于OO 分析方法，现在很多职业学校和社会培训，基础课程从数据库开始，从某种程度上，是历史倒退， 严重阻碍中国软件发展的进程。

围绕数据库分析极其容易导致过程化设计编程，围绕数据分析和过程化编程是一对恶魔，数据库结构确立后，就让普通程序员写SQL 语句，SQL语句执行有明显的先后顺序，在这样顺序过程编程思维中，OO思维就难以生存。长此以往，成为习惯后，就很难改变到 OO设计上，所以，传统编程经验越丰富，转变到OO设计就越难。

在运行性能方面：围绕数据库分析设计容易导致软件运行时负载集中在数据库端，系统性能难于扩展（走上集中式、昂贵的、高风险的大型机模式）， 闲置了中间件J2EE服务器分布式集群处理能力，就是使用了集群，也分担不了负载。

最后，我们必须认识到：对象和关系数据库存在阻抗，本身是矛盾竞争的，他们是两种分析看待需求的流派，可以说是水火不容， 要么你采取数据库分析设计以及过程化编程，要么完全采取OO，现在使用.NET和Java这样OO语言的人很多，但是70%左右都是使用OO语言
编写传统过程化系统，在Java中这样做，会有极差性能；而这种现象在.NET中又极容易得到纵容，.NET是一个系列阵营，正如Windows系列一样， 当你和别人说，你在使用Windows，别人可能觉得你没有落后时代，但是他们哪里知道你在使用Windows 3.1呢？

第二阶段：面向对象的分析设计方法诞生后，有了专门的分析和设计阶段之分，我们使用UML符号来表达分析设计思想，分析设计进入了一个相对更高的层 次，拥有了自己一套科学且艺术的方法论。但是有一个致命缺点：分析阶段和设计阶段是断裂的，互相不能很好衔接，为什么？

首先，我们看看分析人员和设计人员在职责重点工作是什么？
分析人员的职责：是负责从需求领域中收集基本概念。而设计人员的职责：必须指明一组能北项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程序出现的问题 两个阶段两者目标不一致，分析人员只管需求分析，至于是否适合设计，或者能够导出适宜设计的分析结果，这个尺度很难衡量和把握；

而设计人员因为照顾代码可运行，因此，经常可能会抱怨分析员给出的结果过于粗糙，不适合设计，这样分析设计两个阶段就导致分裂，项目失败。

　　在这个阶段，虽然有UML帮助，但是UML不是思想，打个比喻：会CAD的绘图员就是建筑师吗？很显然，UML就是CAD图符号，UML不等于分析设计思想。 所以，有人说UML不是银弹，这些就象说中医不是科学一样绕人（中医就不是西医，当然就不是科学）。

第三阶段：融合了分析阶段和设计阶段的领域驱动设计（Evans: DDD）。2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD， 领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道，所以，从Evans DDD通篇文章中，你找不到科学象征的定理和公式，当然如果 你试图寻找这样寻找，你也就陷入了“中医是不是科学”怪圈了。

　　Evans DDD抛弃了分裂分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。 单一的领域模型同时满足分析原型和软件设计 ，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。 建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此，建模专家必须懂设计。

领域建模的重要性

　　如果你说一个软件开发需要经过需求、分析和设计三个阶段的话，那么可能反映你的思想已经落伍，软件开发现在是 经过需求、建模阶段，混合了分析和设计阶段，可以更激进地说：我们国家的系统分析员和系统设计员考试也许应该合并了， 合并成建模专家的考试，否则，这些都是中国软件落后世界十年的证据，可悲的是：我们自己可能都不知道。

Evans DDD可以说是近期与SOA相提并论的两大重要技术思想，SOA是着重于软件集成方面；而EvansDDD才是着重我们软件开发上， 在大部分情况下，软件开发重要程度不亚于软件集成，但是因为软件开发方面开源力量冲击，软件集成上工业厂商利润最高， 所以，工业厂商在SOA叫得最响，我们参加得各种会议几乎都是SOA，当心被误导，工业厂商从来不会告诉你事实得争相。

　　 没有面向对象的分析设计，哪里面向对象的构件或组件？过去经验不是证明：我们使用大量的构件组件，却在编制面向过程的体系？

以EJB2为例子，在EJB2过去大部分系统中，我们常常以数据库为中心，实体Bean因为特殊技术原因，僵硬一块，变成数据库 的代名词，我们围绕实体Bean编制出大量的值对象Vale Obejct，或称为DTO（Data Transfer Object），在这样系统中，从对象 的名称也可以看出，对象是为数据服务的，对象从属于数据库的。

现在，要彻底改变过来，OO就是以对象为主，数据库是从属对象设计的，如果说EJB2的实体bean技术让你不得不走上传统过程化编程歧路，那么 EJB3已经更正了实体Bean设计缺陷，从EJB发展可以看到一个侧面：工业厂商更多关心的是功能，而不是设计？

只有谁才真正关心你的软件设计和代码质量？只有你自己。我不是提倡都不要参加工业厂商的会议，而是需要每个人冷静想想： 到底谁是自己代码的主人？

　　领域建模属于与具体.NET或Java技术无关的设计思想，有人总是说：.NET比Java简单，其实这又是一个大误区，如果都达到同样设计水准，无论使用.NET或Java，都需要付出同样的努力；那为什么有人觉得.NET简单，那是因为设计要求降低了，参见这篇.NET的DDD文章。

分层架构

　　分层架构是现代OO软件企业系统的基本架构，只有分层才能达到良好的可拓展性和维护性。基本三层：表现层、业务层和持久层 ;J2EE中表现层和持久层有成熟框架支持，应用重点在业务层。

业务层根据Evans DDD，可以再细分为应用层和领域层两种，在业务层设计编码中，大量应用OO设计原则和设计模式。领域层定义：负责表达业务领域概念、业务状态以及业务规 则，是整个业务软件核心和重点。 应用层定义：负责完成功能，并且协调丰富的领域对象来实现功能，不能包括业务规则，无业务状态；

　　每个层都是内聚的，并且只依赖它的下层，为了实现各层的最大解耦，IOC/DI容器是当前Java业务层的最好选择 。

　　 没有分层架构的快速开发基本是旁门左道，不如返回Foxpro和Delphi/VB两层时代。将本属于业务层的逻辑交由表现层来处理的快速UI方式也是一种旁门左道。快速开发必须基于良好的质量，虽然良好的分层架构带来开发效率的降低，但是这些也是可以有方法解决。

建模与项目管理

在我们大多数从软件项目管理上寻找软件永恒解决之道时，他们可能没有意识到又在范“缘木求鱼”老毛病了， 打个比喻很容易明白这个道理：冷兵器时代（也就是火枪没有没有发明之前），各种排兵布阵可能在作战指挥时 很有效；但是到了火器时代，所有的过去作战方式就落伍了；当然到了现在信息化战争时代，更是天壤之别。

　　 Evans DDD领域驱动建模的诞生，对过去传统的项目管理都提出挑战，当我们还在争论RUP好还是敏捷好的时候， 谁会想到我们应该采取围绕统一领域模型的迭代驱动开发呢？

　　 有人可能还在疑惑？我接到一个大项目，那么我的建模和架构设计时间应该是5个月还是5年呢？当然应该回答他：都不行，需求是多变且复杂的，计划赶不上变化，现在就应该开始DDD建模。

(以上文字源自板桥本人的第四届中国软件技术大会“领域设计建模”演讲稿 )

相关文章：

当前Java项目开发中几种认识误区

领域建模之建模设计系列

实战DDD(Domain-Driven Design领域驱动设计)

JavaEE/J2EE面向对象编程之道

Feature-Driven Development特征驱动开发

快速适应需求变化的软件复用

Java企业系统架构选择考量

数据库时代的终结

数学建模对程序设计的影响

两年的技术经历，在J2EE上疑惑?

致面向对象技术初学者的一封公开信

贫血和充血模型的比较之我见

更多关于DDD讨论

发表讨论

使用， 可以集成到JBossAS应用，也可以集成到其他的应用服务器上。TreeCache是一种树状结构，每个节点拥有一个名字和多个或者没有子节点，除跟节 点没有子节点其他节点有且只有一个父母节点，可以通过路径名来访问子节点（FQN：Full   Qualified   Name），在一个TreeCache中可以存在多棵树，，即可以有多个根节点。当应用于分布式环境时，由于TreeCache是基于复制的，每个子节点的值必须是可序列化的。  
            在下面中，将通过例子来了解TreeCache的功能及其配置，使用JBossCache1.4和JDK5.0。首先是一个最基本使用TreeCache 的程序例子并配置一个TreeCache的配置骨架（各种常用的配置可参见jboss-cache-dist-1.4.0.CR1版本的etc目录，如下 各种配置参考也可见该目录下的范例配置，以下不再强调），见下：  
  [code]  
  TreeCache   tree   =   new   TreeCache();  
  tree.setClusterProperties("treecache.xml");    
  tree.createService();    
  tree.startService();    
  tree.put("/a/b/c",   "name",   "Ben");  
  tree.put("/a/b/c/d",   "uid",   new   Integer(322649));  
  Integer   tmp   =   (Integer)   tree.get("/a/b/c/d",   "uid");  
  tree.remove("/a/b");  
  tree.stopService();  
  tree.destroyService();    
  [/code]  
  [code]  
  treecache.xml：  
  <server>  
          <mbean   code="org.jboss.cache.TreeCache"  
                  name="jboss.cache:service=TreeCache">  
                  <depends>jboss:service=Naming</depends>  
                  <depends>jboss:service=TransactionManager</depends>  
                  <attribute   name="ClusterName">TreeCache-Cluster</attribute>  
                  <attribute   name="ClusterConfig">  
                          <config>  
                                  <UDP   mcast_addr="228.1.2.3"   mcast_port="48866"  
                                          ip_ttl="64"   ip_mcast="true"    
                                          mcast_send_buf_size="150000"   mcast_recv_buf_size="80000"  
                                          ucast_send_buf_size="150000"   ucast_recv_buf_size="80000"  
                                          loopback="false"/>  
                                  <PING   timeout="2000"   num_initial_members="3"  
                                          up_thread="false"   down_thread="false"/>  
                                  <MERGE2   min_interval="10000"   max_interval="20000"/>  
                                  <FD_SOCK/>  
                                  <VERIFY_SUSPECT   timeout="1500"  
                                          up_thread="false"   down_thread="false"/>  
                                  <pbcast.NAKACK   gc_lag="50"   retransmit_timeout="600,1200,2400,4800"  
                                          max_xmit_size="8192"   up_thread="false"   down_thread="false"/>  
                                  <UNICAST   timeout="600,1200,2400"   window_size="100"   min_threshold="10"  
                                          down_thread="false"/>  
                                  <pbcast.STABLE   desired_avg_gossip="20000"  
                                          up_thread="false"   down_thread="false"/>  
                                  <FRAG   frag_size="8192"  
                                          down_thread="false"   up_thread="false"/>  
                                  <pbcast.GMS   join_timeout="5000"   join_retry_timeout="2000"  
                                          shun="true"   print_local_addr="true"/>  
                                  <pbcast.STATE_TRANSFER   up_thread="true"   down_thread="true"/>  
                          </config>  
                  </attribute>  
          </mbean>  
  </server>  
  [/code]  
            其中ClusterConfig配置在前面JavaGroups的介绍详细介绍，其它配置比较简单，需要进一步了解请参见TreeCache文档。

一、Cache分类  
            TreeCache按功能分为三类：本地(Local)Cache、复制(Replication)Cache和失效(Invalidation) Cache。本地Cache只应用于本地环境，后两个Cache可应用于分布式环境，其中，在分布式环境中，复制Cache当一个Cache实例的一个节 点值发生变化时会将变化复制到其它实例中，而失效Cache是当一个Cache实例的一个节点值发生变化时会将其它实例的相应节点的值设为空，让其重新去 获得该值，可通过这种方式缓存大对象以减少在实例中复制对象的代价。分布式Cache（复制和失效Cache）又分为两种，同步（REPL_ASYNC） 和异步（REPL_SYNC），同步Cache是在一个Cache实例做修改时，等待变化应用到其它实例后才返回，而异步Cache是在一个Cache实 例做修改时，即刻返回。其配置见下：  
  [code]  
  <!--  
        Valid   modes   are   LOCAL  
                                        REPL_ASYNC  
                                        REPL_SYNC  
                                        INVALIDATION_ASYNC  
                                        INVALIDATION_SYNC  
  -->  
  <attribute   name="CacheMode">REPL_SYNC</attribute>  
  [/code]  
            二、事务和并行(Transaction   And   Concurrent)  
              TreeCache是一种事务Cache，与JDBC一样，其包括两方面内容：锁和隔离级别。锁分为悲观锁和乐观锁，当使用悲观锁时，分为五个隔离级别， 分别是SERIALIZABLE、REPEATABLE_READ   (default)、READ_COMMITTED、READ_UNCOMMITTED和NONE，隔离级别逐步减弱。乐观锁也叫版本锁，其对

数据进 行操作时，将其复制到临时区，操作之后将版本与原有数据比较，如果一致则将递增版本并写回，如果不一致则回滚，由于乐观锁仅在复制出数据和提交数据时对数 据加锁，所以并行度更高，但如果写操作比较频繁地话则容易出现冲突导致回滚。TreeCache默认使用悲观锁。使用TreeCache时，需要使用容器 提供的事务管理器，一般使JBossTransactionManagerLookup和 GenericTransactionManagerLookup，前者应用于JBOSS服务器，后者应用于其他服务器，也可使用DummyTransactionManagerLookup用于测试。如上介绍的配置如下：  
  [code]  
                <attribute   name="NodeLockingScheme">OPTIMISTIC</attribute>  
                <attribute   name="IsolationLevel">REPEATABLE_READ</attribute>  
              <attribute   name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>  
  [/code]  
            三、逐出策略(Eviction   Policy)  
              由于内存数量的 局限，不可能将所有的Cache数据存放在内存中，但使用内存达到一定极限时，会将部分数据清除出内存，保存到其它持久媒质中，定义的什么时候清除、如何 清除的策略就是逐出策略。自定义一个逐出策略需要实现org.jboss.cache.eviction.EvictionPolicy、 org.jboss.cache.eviction.EvictionAlgorithm、  
    org.jboss.cache.eviction.EvictionQueue   和org.jboss.cache.eviction.EvictionConfiguration四个接口，系统提 供了LRU(Least   recently   used，最近最少使用)、LFU(Least   Frequently   Used最不经常使用)、FIFO(First   In   First   Out先进先出)、MRU(Most   Recently   Used最近最经常使用)四种实现，详细参见org.jboss.cache.eviction包的源代码。配置如下：  
  [code]  
  <attribute   name="EvictionPolicyConfig">  
        <config>  
              <attribute   name="wakeUpIntervalSeconds">5</attribute>  
              <region   name="/_default_">  
                  <attribute   name="maxNodes">5000</attribute>  
                  <attribute   name="timeToLiveSeconds">1000</attribute>  
              </region>  
              <region   name="/org/jboss/data"  
  policyClass="org.jboss.cache.eviction.FIFOPolicy">  
                  <attribute   name="maxNodes">5000</attribute>  
              </region>  
              <region   name="/test/"   policyClass="org.jboss.cache.eviction.MRUPolicy">  
                  <attribute   name="maxNodes">10000</attribute>  
              </region>  
              <region   name="/maxAgeTest/">  
                  <attribute   name="maxNodes">10000</attribute>  
                  <attribute   name="timeToLiveSeconds">8</attribute>  
                  <attribute   name="maxAgeSeconds">10</attribute>  
              </region>  
        </config>  
  </attribute>  
  [/code]  
            也可以多对所有的区域定义同样的逐出策略  
  [code]  
  <attribute   name="EvictionPolicyClass">org.jboss.cache.eviction.LFUPolicy</attribute>  
  [/code]  
            四、Cache加载  
          由于逐出策略的存在，那么当我们重新需要获得一个原来在缓存中但确由内存原因被逐出的数据时，就需要定义一种加载策略，使地可以重新找回数据，同时，Cache加载也肩负在将数据逐出时将数据保存到持久媒质的责任。  
          根据将数据保存媒质的不同，Cache加载包括FileCacheLoader、JDBCCacheLoader等等，可以同时使用多种加载器来灵活定制加载策略。例见下：  
  [code]  
  <attribute   name="CacheLoaderConfiguration">  
          <config>  
                  <passivation>false</passivation>  
                  <preload>/</preload>  
                  <shared>true</shared>  
                  <cacheloader>  
                          <class>org.jboss.cache.loader.ClusteredCacheLoader</class>  
                          <properties>  
                                    timeout=1000  
                          </properties>  
                          <async>true</async>  
                          <fetchPersistentState>false</fetchPersistentState>  
                          ignoreModifications>false</ignoreModifications>  
                          <purgeOnStartup>false</purgeOnStartup>  
                  </cacheloader>  
                  <cacheloader>  
                          <class>org.jboss.cache.loader.JDBCCacheLoader</class>  
                          <properties>  
                                                  cache.jdbc.table.name=jbosscache  
                                                  cache.jdbc.table.create=true  
                                                  cache.jdbc.table.drop=true  
                                                  cache.jdbc.table.primarykey=jbosscache_pk  
                                                  cache.jdbc.fqn.column=fqn  
                                                  cache.jdbc.fqn.type=varchar(255)  
                                                  cache.jdbc.node.column=node  
                                                  cache.jdbc.node.type=longblob  
                                                  cache.jdbc.parent.column=parent  
                                                  cache.jdbc.driver=com.mysql.jdbc.Driver  
                                                  cache.jdbc.url=jdbc:mysql://localhost:3306/jbossdb  
                                                  cache.jdbc.user=root  
                                                  cache.jdbc.password=  
                            </properties>  
                            <async>true</async>  
                            <fetchPersistentState>false</fetchPersistentState>  
                            <purgeOnStartup>false</purgeOnStartup>  
                    </cacheloader>  
          </config>  
  </attribute>  
  [/code]  
          我们将通过定制如上的配置信息以更有效地使用JBossCache。详细情况可参考JBoss   TreeCache参考文档和范例。