主持人 说:
架构基础 (Concept Of Architecture)
架构基本概念 (Basic Concept)
架构设计目标 (Goals)
架构分类 (Categories)

企业级应用架构 (Enterprise Architecture)
架构组成 (Constitution)
架构设计原则 (SOA)
架构实现方法论 (Methodology)

火龙果架构培养体系
企业级架构案例 (Example)
架构设计路线图-火龙果软件
确定架构设计范围
子架构：分析、设计、实现与验证
功能架构：子系统划分
逻辑架构：系统分层
可扩展架构：支持的资源扩展
外部接口架构：系统外部接口支持多种交互协议
可靠性架构：异常处理机制
可维护性架构：运行时的扩展性
集成系统总体架构
集成的时机
逻辑架构集成
物理架构集成
集成策略
架构集成验证
主持人 说: 今晚交流的范围是这个
主持人 说: 这个是 讲义 http://www.uml.org.cn/MyProcess/GuideView/ziliao/yyjgshj-080731.rar
主持人 说: http://www.uml.org.cn/MyProcess/GuideView/ziliao/final-080731.rar 这个是视频
主持人 说: 架构是个很大的话题，可谓仁者见仁，智者见智，一会欢迎深入讨论，欢迎独到见解
Rainbow! 说: hi
主持人 说: 好
主持人 说: 主讲嘉宾：谢峰来了
主持人 说: 听说路上堵，出了一身汗吧，呵呵
Rainbow! 说: 大家好
Rainbow! 说: 不好意思，今天堵车，呵呵
wate 说: 谢老师好
weining45@126.com (E-mail Address Not Verified) 说: 谢老师好
Rainbow! 说: 很高兴和大家交流
yigang75@hotmail.com 说: 谢老师好
Rainbow! 说: 大家好
主持人 说: 先介绍一下谢老师：谢峰，系统架构师，上海交通大学硕士。
有多年的J2EE开发和架构设计经验。从事过大型物流软件的架构设计，企业基础平台的设计和开发。目前主要工作是设计基于银行金融业务的企业级架构，和Business Intelligence的应用。
主要特长：面向对象设计与分析，设计模式, UML, J2EE各种技术的综合应用，
分布式计算模型，Richclient Internet Architecture(RIA)架构设计，Web2.0架构设 计,
企业级架构整合,商业智能。
著作：《分布式模型改进方案》《基于智能客户端的企业基础平台的设计》
主持人 说: 交流方式：通过在线的方式交流关于《应用架构设计实践》的一些经验，并对先前发布的视频<<应用架构设计实践>>进行答疑，答疑范围包括但不限于本视频，参与讨论者可以提出自己在应用架构设计中的相关问题。本次交流适用于一切对架构设计与应用感兴趣的软件行业从业者。
Rainbow! 说: 大家都看过ppt了没
wate 说: 看了
wate 说: 感觉挺好
wate 说: 有问题呢
Rainbow! 说: 呵呵，谢谢
Rainbow! 说: 恩，欢迎提问题
主持人 说: 大家有什么问题，欢迎在这里交流，
主持人 说: 同时欢迎发表自己的见解，共同探讨
wate 说: 现在我们在一个项目的开始阶段
wate 说: 按照过程计划：需求，架构设计，详细设计
wate 说: 不知道架构设计做些什么
wate 说: 谢老师能讲一下么
Rainbow! 说: 呵呵，好的
Rainbow! 说: 架构设计，其实有别于传统的过程化开发面膜时
Rainbow! 说: 他是对一个系统的一种有机化的组织和协作
Rainbow! 说: 当然拉，说白了，架构设计有点像盖房子，先画图纸，再进行施工
wate 说: 具体要做什么呢
Rainbow! 说: 对于目前大部分应用软件或者项目的架构设计而言
Rainbow! 说: 架构设计分这么几块
Rainbow! 说: 一个是规划具体软件的子系统，也就是我们常说的模块，或者流行语言就是组件
Rainbow! 说: 规划这些子系统的职责，以及他们之间的协作关系
Rainbow! 说: 再者，就是对软件进行建模
李志强 说: 是先找用例，再划分系统呢，还是先划分？
Rainbow! 说: 应该是按照需求，划分子系统，可以说现有use case吧
Rainbow! 说: 对软件建模
wate 说: 用例是需求吧
Rainbow! 说: 恩，可以这么说
Rainbow! 说: 对软件建模一般分为这么几种情况
Rainbow! 说: 领域建模，也就是对你软件的需求或者说Business Logic进行建模
Rainbow! 说: 包括领域实体建模，以及Business Process建模
Rainbow! 说: 还有就是按照通用性和定制性，构建架构基线
Rainbow! 说: 也就是我们常说的Framework
yigang75@hotmail.com 说: 在进行领域建模时是否与OO方法没关系呢？
wate 说: 架构基线主要是什么，
Rainbow! 说: 架构基线是一个“小的、皮包骨架的”系统，是系统整个生命周期的开发准则，适用于所有的迭代周期
Rainbow! 说: 这个是他的概念，我用比较流行的方式解释
李志强 说: 领域建模应该是业务层面的吧
Rainbow! 说: 对
Rainbow! 说: 在我的理解中，架构基线在大部分情况下，应该是非功能性框架
Rainbow! 说: 比如我们常用的struts, spring,hibernate等等，这些构建的一个软件的基础结构，可以称为架构基线
李志强 说: 还是不太明白架构基线
Rainbow! 说: 其实可以这么理解，在没有基线的时候，比如，我们需要开发一个应用，可能我们就按照现有的工具，以及客户的定义，逐个开发
Rainbow! 说: 拿这种情况下，可能有一部分的功能，尤其是非功能性需求的那些模块，你开发人员A会自己实现一套，B也会实现一套
Rainbow! 说: 而其实现的效果都是一样的
Rainbow! 说: 那有了架构基线之后呢，我们就会把这些公用的功能进行抽取
Rainbow! 说: 抽取最后的结果就是形成了架构基线
Rainbow! 说: 而对于下次开发的时候，我就会和A和B说，你不用重复开发这个功能了，我们已经有了实现
Rainbow! 说: 其实如果从面向对象的概念来解释，也就是架构基线可以在整个软件开发的生命周期中都能被reuse
wate 说: 哦
Rainbow! 说: 而从面向对象设计的角度而言，架构基线帮你完成了整个软件的通用性功能。
wate 说: 业务架构和企业架构，技术架构，具体都指什么
Rainbow! 说: 业务架构
Rainbow! 说: 也就是我们常说的Business Application Architecture，是对需求的描述，以及业务模型的定义，其中包括领域模型(Domain Object),业务流程模型(Business Process Model),系统参与者(Actor)
李志强 说: 到底是通用功能，还是通用的开发框架
wate 说: 我很少考虑业务架构和企业架构
Rainbow! 说: 企业架构：指的是在对一个企业的业务战略和流程理解基础之上，进行信息化的顶层设计，对企业现有的业务架构和技术架构进行有效的整合，形成灵活健壮的IT结构，构建的和谐IT环境
Rainbow! 说: 到底是通用功能，还是通用的开发框架
-〉是这么理解的，通用的开发框架实现了通用的功能
Rainbow! 说: 比如，分布式系统，我们在通用的开发框架中实现了基于RMI-IIOP的分布式通信
Rainbow! 说: 好的架构就可以使得开发人员无须关心具体的通信方式，而由通用的开发框架来帮你完成
weining45@126.com (E-mail Address Not Verified) 说: 谢老师我想问一下，一般对于非功能性需求，我简单认为主要指的是性能要求，那么非功能性架构指的是？
Rainbow! 说: 或者再简单一点的例子，Spring就是一个通用性的开发框架，他帮你实现了AOP和IOC注入，这对于开发人员来说无须关心
gooder (E-mail Address Not Verified) 说: 我来了
wate 说: 我很少考虑业务架构和企业架构
-〉业务架构其实我们几乎所有的系统都会有，业务架构就是对需求的一个建模，或者说一个不涉及具体技术的领域模型，这些建模包括Use Case的定义，Business Sequence的定义，Domain Object的定义，以及这些对象之间的协作，任何应用系统都不可能脱离这些而存在
Rainbow! 说: 企业架构，这是最近几年比较兴起的一个概念
Rainbow! 说: 用两个字来形容，“整合”
wate 说: SOA么
Rainbow! 说: 对，SOA只是其中的一种设计方式
Rainbow! 说: 他的目的是在宏观上对各种Application或者说System进行规划
主持人 说: 刚才有个问题：谢老师我想问一下，一般对于非功能性需求，我简单认为主要指的是性能要求，那么非功能性架构指的是？
Rainbow! 说: 通过SOA的方式，使得这些Application或者System进行有机的协作
Rainbow! 说: 刚才有个问题：谢老师我想问一下，一般对于非功能性需求，我简单认为主要指的是性能要求，那么非功能性架构指的-〉
Rainbow! 说: Non-Functional需求
Rainbow! 说: 一般指的是技术需求，和具体的业务没有直接的关系
weining45@126.com (E-mail Address Not Verified) 说: 哦，我就是想问，非功能性架构是否可以理解为性能架构？
Rainbow! 说: 非功能性架构也可以成为技术架构，
Rainbow! 说: 性能只是非功能性架构的一部分
Rainbow! 说: 对系统使用的技术一个规范性的定义，它包含非功能性的可重用构件，系统结构的设计规范，开发规范，物理环境，测试环境，部署环境的定义，以及系统配置管理
weining45@126.com (E-mail Address Not Verified) 说: 哦
Rainbow! 说: 我举一些例子，可能你就会明白了
Rainbow! 说: 比如我刚刚提到的一个分布式系统
Rainbow! 说: 我在设计这种分布式系统时，一般都会抽取一个通讯层
Rainbow! 说: 里面会包含各种通信的方式，比如Socket, RMI-IIOP, Https等等
Rainbow! 说: 这些需求，you can image， 是和具体业务没有直接关系的
Rainbow! 说: 你提到的性能，会作为其中的一个设计要求来考虑
weining45@126.com (E-mail Address Not Verified) 说: 嗯，但是性能针对不同的应用会有不同的要求，不可以重用对吗？
Rainbow! 说: 这类例子还有很多，比如你的系统的表现层框架，用B/S还是C/S，持久层的选型，EIS层的选型，这些和具体Business Logic没有直接关系，这些都是非功能性架构的一部分
主持人 说: 非功能架构也可以和非功能性需求对应吧：性能，可靠性，安全，可扩展，可用性
weining45@126.com (E-mail Address Not Verified) 说: 前面提到技术架构包括系统结构的设计规范的定义，如何进行定义？定义些什么？
李志强 说: 性能的要求可能会影响整体的架构调整
Rainbow! 说: 这个可能就要视具体情况而定了，可以这么说，如果我来设计一个非功能性架构，遇到了你所提的这个问题，“针对不同的应用会有不同的要求”，我会采用Strategy的方式，抽取通用的非功能性行为，而针对不同应用使用不同的实现
Rainbow! 说: 前面提到技术架构包括系统结构的设计规范的定义，如何进行定义？定义些什么？
Rainbow! 说: 这个概念可以这么理解
Rainbow! 说: 我先说明一个简单的例子
李志强 说: 请教谢老师，对于一个500用户分布式系统，和一个10W用户的系统，在架构设计上应该注意哪些呢
gooder (E-mail Address Not Verified) 说: 如果设计一个架构，具体的行动过程是什么呢
Rainbow! 说: 非常简单，几乎所有的系统在实现时，都会遇到字符串处理问题，比如，判空，分割等等，可能没有技术架构时，我们都会自行按照我们的knowledge来实现，而有了技术架构后呢，我们会对这些字符串处理的行为进行提炼，提炼成StringUtilities对象，然后再具体的实施过程中，就规定必须使用StringUtilities来处理字符串，这其实就是一个最简单的设计规范的定义
Rainbow! 说: 那对于更高层次的定义，可以理解为基于整个架构开发的一个Guideline，比如对于分布式模型，表现层的对象不能直接实例化业务层的对象，或者说表现层和业务层的通讯必须基于框架提供的通信组件来完成
Rainbow! 说: 那对于更高层次的定义，可以理解为基于整个架构开发的一个Guideline，比如对于分布式模型，表现层的对象不能直接实例化业务层的对象，或者说表现层和业务层的通讯必须基于框架提供的通信组件来完成
Rainbow! 说: "请教谢老师，对于一个500用户分布式系统，和一个10W用户的系统，在架构设计上应该注意哪些呢",
呵呵，这个问题厉害
Rainbow! 说: 其实这种情况，我是这么理解的，我们不是万能的，在架构设计之初会考虑到今后各种可能的变化，而当遇到类是的需求变化时，就要考虑采用外围的方式来解决。
gooder (E-mail Address Not Verified) 说:
Rainbow! 说: 我只的外围
Rainbow! 说: 是说，在尽量不去修改原有架构的基础上
Rainbow! 说: 当然如果你说原来架构设计的，一塌糊涂，神仙也难就，想重头来过，那我也没话说，呵呵
Rainbow! 说: 对于你这个问题，一般而言，几种方式
Rainbow! 说: 一个地球人都知道，集群
Rainbow! 说: 还有一种，就是采用不同的缓存技术
Rainbow! 说: 不同策略的
Rainbow! 说: 比如对于一些不同层面实现那些不易变的数据缓存
Rainbow! 说: 或者按照策略实现分级缓存
wate 说: 是啊
Rainbow! 说: 曾经我也有过类是问题
wate 说: 集群，缓存
Rainbow! 说: 我们设计的基于Smart Client的分布式系统，在用户数到达一定程度的时候，发现速度急剧下降
Rainbow! 说: 后来才发现，其原因在于，很多业务数据处理，都需要Server端提供国家，城市，等地址信息，而这些信息又不是易变的
Rainbow! 说: 而且也比较大，后来，我们就利用Smrat Client技术的特点，将这些不易变的数据在Client进行缓存
Rainbow! 说: 速度得到明显改善
Rainbow! 说: 我这只是说明了一个简单的例子
Rainbow! 说: 对于复杂情况而言，还需要对现有架构的业务架构和技术架构进行分析，
李志强 说: 思路不错，谢谢谢老师，呵呵
Rainbow! 说: 对业务架构分析是否设计的合理，Business Sequence是否可以进行优化，比如通过Delegate Pattern来降低分布式的通讯，使用coarse-grained接口统一协调Business Process。
weining45@126.com (E-mail Address Not Verified) 说: 谢老师，前面讨论先有用例，再进行子系统的划分，那么在分析了系统的用例之后，如何进行子系统的划分呢？子系统划分的原则是什么？
Rainbow! 说: 呵呵，谢谢
Rainbow! 说: 对于技术架构，分析就是考虑如何通过统一的方式降低各种层面交互的开销，比如采用数据压缩，或者缓存。同时也需要对已采用的缓存策略进行分析，分析其是否合理，是否符合应用的要求。比如一个对数据库更新操作非常频繁的系统，采用hibernate做持久层，如果使用了2级缓存，反而降低了持久层的性能。
Rainbow! 说: 谢老师，前面讨论先有用例，再进行子系统的划分，那么在分析了系统的用例之后，如何进行子系统的划分呢？子系统划分的原则是什么？
Rainbow! 说: 我主要归结于以下几点
Rainbow! 说: 分而自治：确定子系统的责任边界
面向服务：子系统交互面向接口，确定服务范围
协同规划：子系统定义需要有整体规划，划分时需要考虑多个子系统的协作关系，以及子系统组合后提供的高层次子系统的职责。
Rainbow! 说: 其中第一条非常重要
wate 说: 具体说说？
Rainbow! 说: Responsibility Boundary可以使整个软件系统结构化变得十分清晰
Rainbow! 说: 对于，每个子系统的设计和开发人员而言，通过明确的边界定义，他们可以清楚地认识到自己的职责，可以更好的focus在本系统的业务逻辑的实现上。
Rainbow! 说: 对于团队协作开发而言
wate 说: 架构 设计好了，维护有什么原则吗?
wate 说: 目前设计，总是预测不如变化快
wate 说: 怎么把握呢
weining45@126.com (E-mail Address Not Verified) 说: 那么子系统的功能是越少越好吗？如何才能保证划分的合理？
Rainbow! 说: Responsibility Boundary可以使得系统的并行开发变得十分轻松，对于别的子系统的依赖，也可以通过定义Mocker来完成。
Rainbow! 说: 维护有什么原则吗?
Rainbow! 说: 可维护性主要体现在两个方面
Rainbow! 说: 架构的易用性，架构对于架构使用者应该可以很方便的被使用，包括代码的实现，基于架构代码的可读，架构的参数配置等等。
基于架构的应用的可维护性，这主要指的是基于架构实现的应用系统，可以很方便的被维护，其中包括，应用的安装部署，应用的使用，以及应用的配置。这些特性也是有架构设计来决定的。
Rainbow! 说: 具体实现方式，按照我的理解可以归结于
Rainbow! 说: 对于架构的易用性而言，架构设计主要体现在对通用性行为定义的合理性，以及对于需要定制行为接口的明确性两方面。通用性行为如果抽象的比较合理，那么可以使得基于架构的开发变得非常容易，需要定制接口的行为明确可以使基于架构开发的代码可以很易读。
Rainbow! 说: 对于应用可维护性而言，一般采用的方式有是，定制合理的系统配置参数，也就是说系统配置参数不易过多，或者说可以提供一些默认的系统配置参数。对于那些需要经常改变的应用配置，要提供简单的维护方式，比如ppt中提到的Report Repository，对于易边的报表模版，数据模版，组件都采用了简单易用的操作系统提供的文件系统来维护。
Rainbow! 说: 当然还有一点需要强调，对于一些复杂的安装配置，要尽量集中管理，比如对于一些Rich Client应用程序来说，Rich Client一些相关的配置参数，不应该在Client安装的时候来进行设定，而应该在Server段进行集中统一的配置管理。
Rainbow! 说: 那么子系统的功能是越少越好吗？如何才能保证划分的合理？
weining45@126.com (E-mail Address Not Verified) 说: 例如底层的通信，我们可以划分一个专门用于建立连接的子系统，和一个专门准备传输数据的子系统，这样各子系统的责任边界非常明确，但是增加了各子系统之间传送的接口
Rainbow! 说: 当然事情都不能走极端化，这主要取决于在架构设计之初，对于整个需求定义的粒度划分
Rainbow! 说: 对于扩展性要求不高的系统，子系统可以划分的粗一点，没必要要求每个功能点都能被重用
wate 说: 重用有什么原则
Rainbow! 说: 对于扩展性或者说弹性要求比较高的系统，比如那些大型的ERP产品，其面向的是一个特定行业的通用性软件，可能很多子系统在不同情况组合单独形成一个应用，这种情况下，就需要对这些功能进行细分，确立最小的可重用的粒度单位
Rainbow! 说: 按照粒度单位来划分子系统，比如物流软件里面的空运模块，海运模块等等
weining45@126.com (E-mail Address Not Verified) 说: 哦
Rainbow! 说: 我个人认为，针对不同系统而言，可以采用不同的设计方式，比如你提到的“准备传输数据的子系统”，其可扩展性要求不高
Rainbow! 说: 或者说通用性比较强，我就认为他可以不用单独成为一个子系统
Rainbow! 说: 还有说，数据传输和通信两者是绑定的存在的，那也没必要划分成两个子系统
Rainbow! 说: 因为他们组合完成了一个功能，按照职责划分的原则，可以将这两者结合作为一个子系统
gooder (E-mail Address Not Verified) 说: 谢老师可以说说重用的原则么
Rainbow! 说: 恩
Rainbow! 说: 重用其实就是对通用的行为的一种抽象以及提取
Rainbow! 说: 我个人认为，重用的原则划分，可以按照功能的通用性，逐一封装
Rainbow! 说: 还是具刚刚那个例子
李志强 说: 个人认为重用分成几个层面
Rainbow! 说: 比如字符串处理，日期处理，Collection处理，这些重用性很高
Rainbow! 说: 对，我同意
wate 说: 哪些层面？
Rainbow! 说: 那我们可以对这类功能，进行抽取，提炼，形成一个层面的组件
Rainbow! 说: 恩，大家请看ppt第14个slide
Rainbow! 说: 一般而言，非功能性基础架构，可以看成是一个底层次的重用层面
Rainbow! 说: 他帮你完成了大部分非功能性要求，比如Trace，DB连接，数据库的CRUD操作，或者说分布式通信，Presentation Tier中的Widget， MVC数据绑定
Rainbow! 说: 这些公用的非功能性行为可以看成一个重用的层面
wate 说: 不过看起来他们的面向的层面不同啊
Rainbow! 说: 当然这个层面中还可以细分，比如刚刚说的常用的字符串，日期处理等等，我不再细化
Rainbow! 说: 呵呵，我是从宏观上将重用的层面划分为非功能性，和功能性
wate 说: 哦
Rainbow! 说: 对于功能性重用的划分
Rainbow! 说: 主要是对于各种业务模块共性的抽取，比如物流系统中，海运和空运他们的下订单的方式80%是一样的
李志强 说: 其实单从字面理解很多都可以重用，架构、开发模式、模块、代码、包括泡MM方式，不知道说得对不对
Rainbow! 说: 那就可以对80%的功用特性就行抽取
Rainbow! 说: 形成可重用的业务组件
Rainbow! 说: 哈哈，对
Rainbow! 说: 有兴趣，这个比喻很恰当
wate 说: 呵呵
weining45@126.com (E-mail Address Not Verified) 说: 请谢老师再介绍一下系统分层，好吗？
Rainbow! 说: 有兴趣的话，大家也可以交流一下泡MM的方式，just a joke，言归正传
Rainbow! 说: 好
Rainbow! 说: 架构层次一般分两种概念，功能性层次，比如我们说的分布式模型，有表现层，中间层，持久层，EIS层，功能相近的子系统一般会被归在一个层中，每一个层可以是逻辑上的分层，也可以是物理上的分层。原则就是按功能来划分
Rainbow! 说: 还有一种概念，按照服务的消费者和服务提供者，来划分层次，一般而言，通用性越高的组件，其层次越低，定制性越高的子系统其层次越高。一个很简单的例子，OSI网络7层协议。所以这个另外侧面反应的就是系统间的依赖关系
孤烟 - 雏菊世界 团结起来，藐视一切敌对者 说: Good
Rainbow! 说: 这是我个人理解，不知道大家有何其他观点
孤烟 - 雏菊世界 团结起来，藐视一切敌对者 说: 分层的主要原则是什么，肯定不是越细越好
Rainbow! 说: 恩
Rainbow! 说: 说的对
主持人 说: 分层要遵守单一职责
weining45@126.com (E-mail Address Not Verified) 说: 针对一个系统，我们首先找出该系统的绝大多数用例，然后分析系统的各个功能点，对功能点的通用型和定制性进行分析，进而对系统进行分层。我这样理解过程对吗
Rainbow! 说: 恩
主持人 说: 也就是一个层次应该面向一个变化的角度，或者一个复用的层面
主持人 说: 呵呵
Rainbow! 说: 呵呵，对
孤烟 - 雏菊世界 团结起来，藐视一切敌对者 说: 层间依赖一定是单向的么
Rainbow! 说: 呵呵，至少说不能是双向的
Rainbow! 说: 如果双向的话，就是高聚合
Rainbow! 说: 不能排除这种情况，有些时候也需要高聚合组件，但是这时候why not把这两个组件看成是一个呢
孤烟 - 雏菊世界 团结起来，藐视一切敌对者 说: 可不可能存在一个层面上多个组件的双向依赖
weining45@126.com (E-mail Address Not Verified) 说: 刚才主持人说“分层要遵守单一职责”，如果上面的应用层有多个功能点，职责各异，那是否不能算是同一个分层呢？
李志强 说: 违反了设计的原则
主持人 说: 这要看单一职责的角度了
主持人 说: 比如有5个界面，支持五种数据操作，但是从显示的角度讲，都是一个指责，显示职责
Rainbow! 说: 恩，不排除这种情况出现，事实上也有类shi做法，因为有时候在同一层面有时候需要两个组件公共完成一个功能，而对于别的层面使用别的功能时，又是独立的组件。当然这种设计的结果就是比较混乱，不便于理清组件的依赖关系，和重用
主持人 说: 设计需要找到合适的角度，角度来自于需求的分析和运行的变化
主持人 说: 呵呵，不知道谢老师怎么看
Rainbow! 说: 恩，个人推荐还是单向依赖
孤烟 - 雏菊世界 团结起来，藐视一切敌对者 说: 如果定义出接口，2个组件相互注入应该不算依赖
Rainbow! 说: 呵呵，是的，不同角度可能看到的职责是不同的，在设计过程中需要按照特定的业务需求，来定义具体的职责。
Rainbow! 说: 这位朋友
主持人 说: 职责不同的人有不同的看法，用户看到的职责是业务的划分，开发人员看到的是技术的差别，分层更多的是面向开发者的角度，但是来自于需求的变化以及复杂性
Rainbow! 说: 个人认为
Rainbow! 说: 接口代表的是一个组件的功能和行为
Rainbow! 说: 如果2个组件接口相互依赖的话，还是表示这两个组件的功能有依赖关系
wate 说: 我有个问题：架构设计如何保证质量呢，经常是设计了又改，
Rainbow! 说: 反过来说，这两个组件还是必须同时存在才能完成一个功能
Rainbow! 说: 这个就提到了架构可扩展性
Rainbow! 说: 可扩展架构主要的核心思想就是如何使那些易边的子系统可以被很方便的被替换，或者说子系统升级而不影响到整体的架构。这里我们推荐原则是：
Rainbow! 说: 对架构进行通用性和定制性进行划分：
确定那些是易边的子系统，或者说组件
确定那些是通用的子系统，这类子系统一般都带有公共的特性，不易发生变化。
Rainbow! 说: 对架构进行通用性和定制性结合：
对易边的需要定制的组件外部交互接口时，抽象其通用化功用的行为。
在实现这些组件时，尽量的将那些无法通用化的行为，放在通用的行为内完成。
这也就是我们常说的coarse-grained接口抽象的方式。
在子系统替换时，由于这些系统接口具有很强的通用性，所以可以很方便的被替换。
比如ppt提到的loadReport就是一个很好的例子。
Rainbow! 说: 另外需要提的一点，这种设计的实现，一般采用的都是先接口，后实现的方式，对外部调用者来说，尽量采用面向接口对象的方式。其中有两种方式值得推荐，一种就是广为而知的IOC依赖注入的方式，通过IOC容易来对注入接口的实现对象，具体的实现对象也就是我们说到定制性很强的对象，可以通过配置的方式被IOC容器所构造。还有一种就是典型的设计模式，Factory Pattern + Strategy Pattern，通过工厂类隐蔽实现对象的构造细节。
gooder (E-mail Address Not Verified) 说: 谢老师，这句话怎么理解？在实现这些组件时，尽量的将那些无法通用化的行为，放在通用的行为内完成。
Rainbow! 说: 是这么理解的
Rainbow! 说: 通用化的行为一般被抽取在公共的接口中
Rainbow! 说: 在该组件被使用的时候，一般都会被当作接口的实例对象来使用
Rainbow! 说: 所以对外部使用而言可以，直接使用这些通用的接口。
Rainbow! 说: 对于那些定制的行为，，或者说无法通用化的行为
Rainbow! 说: 如果直接调用这些定制的接口，就使得调用这必须面向具体的实现对象
gooder (E-mail Address Not Verified) 说: 是不是利用多态的技术
Rainbow! 说: 这样的话，不便于组件的重用，所以，我这里指的意思就是，将定制的行为封装在通用的行为中，或者采用多态的方式，来定义定制行为的抽象接口。
wate 说: 我这个问题还没有回答，谢老师：
wate 说: 我有个问题：架构设计如何保证质量呢，经常是设计了又改
Rainbow! 说: 恩，可以这么理解
Rainbow! 说: 呵呵
Rainbow! 说: 这个就要求在架构设计之初，架构保留足够的开放性
李志强 说: 架构一般不会做大的调整，您说的是需求的变更吗？ wate
Rainbow! 说: 或者说扩展性，当然这听上去比较空洞啦
Rainbow! 说: 我的意思就是在设计的时候，需要对需求
wate 说: 呵呵
Rainbow! 说: 进行分析，需要预估一定的扩展空间
Rainbow! 说: 这种一般性好的设计方式，就是我刚刚提到的面向接口
Rainbow! 说: 首先就是抽象系统的行为
wate 说: 有得时候技术把握不准，或者说有些技术是尝试中，拿不准，也有需求不稳定的
Rainbow! 说: 再考虑具体的实现
Rainbow! 说: 当然如果需求变更直接导致原先的架构无法满足要求，那只好推倒重来，或者说大规模重构
Rainbow! 说: 这个我觉得谁都无法给出一个非常合理的答案
Rainbow! 说: 诸位觉得呢
wate 说: 恩，不好解决
wate 说: 不过还是应该有个方法吧
Rainbow! 说: 呵呵，有何高见，大家交流一下
主持人 说: 架构的验证很重要吧
Rainbow! 说: 是的
主持人 说: 谢老师是否可以介绍一下架构的验证方法
Rainbow! 说: 我觉得架构验证包含以下几个方面
Rainbow! 说: 集成测试
Rainbow! 说: 其中包括功能性测试，和非功能性测试
Rainbow! 说: 功能性测试包括各个功能组件的协作是否满足架构设计的业务模型
Rainbow! 说: 业务流程
Rainbow! 说: 测试方法，地球人都知道的黑盒测试和边界测试，赫赫
Rainbow! 说: 非功能性测试
李志强 说: 这个是在架构设计时做，还是后期做，什么时候做，请教？谢谢
gooder (E-mail Address Not Verified) 说: 架构的时候程序要开发到什么程度呢
Rainbow! 说: 主要是验证系统的非功能性要求，包括性能测试，和可操作性测试
Rainbow! 说: 这是一个迭代的过程
Rainbow! 说: 或者说一个持续化的过程
Rainbow! 说: 每一个迭代过程都需要确定这个迭代过程中架构的验证点
weining45@126.com (E-mail Address Not Verified) 说: 集成测试属于架构的验证，那么架构的集成是指什么？
Rainbow! 说: 对于集成测试来说，需要确定集成测试点
Rainbow! 说: 这个可以这么理解
Rainbow! 说: 集成测试是将系统中各个子系统进行整合后的一个综合性测试
Rainbow! 说: 在现代架构集成过程中，已经开始趋向于自动化集成，持续化集成，常用的工具比如ANT, MAVEN, Cruise Control等等，对于已成行的组件化开放方式，系统集成的方式也显得更加宽松，比如我们可以使用Mocker的方式模拟一个为完成功能的组件，这样可以根据集成点的要求方便的调整Mocker的数据或者行为。
Rainbow! 说: 回到验证的问题
谭建新 凤凰涅磐 说: ibm 的 buildforge 也不错啊
Rainbow! 说: 呵呵，有空我去看看
Rainbow! 说: 架构验证，还包含以下几个方面
Rainbow! 说: 依赖验证
Rainbow! 说: 这指的是，在具体的实施过程中，是否满足各个组件是否满足架构预先定义的依赖关系
Rainbow! 说: 如果说，业务需求发现这种依赖关系不合理，那就需要对就架构进行重构
Rainbow! 说: 进入下一次迭代
weining45@126.com (E-mail Address Not Verified) 说: 架构的验证是在关键代码开发完成后进行吗？
Rainbow! 说: 一般而言，应该是在架构基线完成后
Rainbow! 说: 就开始制定软件开发的迭代周期
Rainbow! 说: 验证是在每一个迭代周期末期进行验证
主持人 说: 好,
主持人 说: 时间差不多了
weining45@126.com (E-mail Address Not Verified) 说: 那架构的集成是在什么时候？
主持人 说: 大家还有什么问题么
主持人 说: 呵呵,延长几分钟
李志强 说: 迭代是否可以分成纵向和横向两种
李志强 说: 还有，希望谢老师能提供一些成熟的架构，针对于不同层面的应用
weining45@126.com (E-mail Address Not Verified) 说: 谢谢！：
谭建新 凤凰涅磐 说: 谢谢 rainbow
Rainbow! 说: 还有，希望谢老师能提供一些成熟的架构，针对于不同层面的应用
Rainbow! 说: 呵呵，可以参考ppt第14ge
Rainbow! 说: slide
weining45@126.com (E-mail Address Not Verified) 说: 谢老师，我还有一个问题没有回答：架构的集成是在什么时候？
Rainbow! 说: 迭代是否可以分成纵向和横向两种？ 这个怎么理解？
李志强 说: 有时间好好学习一下
李志强 说: 针对于模块的需求分析、设计、开发、集成，看成纵向
李志强 说: 针对于需求一个层面的迭代看成是横向，可不可以这样理解
Rainbow! 说: 恩，我可以谈谈我的理解
主持人 说: 呵呵,纵向: 不同层次, 横向:不同模块
主持人 说: 不知道对不对
Rainbow! 说: 你说的纵向，面向过程
Rainbow! 说: 你说的横向，应该是面向具体的设计，实现
Rainbow! 说: 也可以说模块，呵呵
Rainbow! 说: 不知道对否
李志强 说: 我们一般是把一些最稳定的user case确定后，进行分析、设计、开发、测试集成
李志强 说: 同时再考虑一些相对复杂、变化的需求
李志强 说: 这种方式算不算迭代呢
gooder (E-mail Address Not Verified) 说: 我的最后一个问题，如何设计 可靠性的架构
Rainbow! 说: 可靠性架构，主要是指系统运行的稳定性。主要通过两个方面来衡量：
性能：系统运行要能满足实际需求所要求的性能；这方面不同的实现技术有不同的衡量方式，比如C++实现的系统，往往会和内存资源的分配和释放的完善性挂钩，而j2EE系统又会与新旧对象比，与GC相关的对象依赖关系来衡量。当然也有一些通用性的方式来提高系统的运行性能，比如缓存，比如集群。在架构设计时，就需要考虑哪些地方该使用缓存，那些情况需要使用集群。不恰当的设计往往会降低系统的性能。比如一个对数据库更新操作非常频繁的系统，采用hibernate做持久层，如果使用了2级缓存，反而降低了持久层的性能。
Rainbow! 说: 另一方面，可靠性体现在对系统的各种异常的处理，这部分就要求架构师能提供一个很合理的机制，来处理系统内部的各种异常情况。
通常我们推荐做法如下：
对异常进行分类，每一个子系统应该有一种自定义的异常标示本子系统发生的错误。
对处理异常的职责进行划分，当一个子系统使用另外一个子系统的服务时，另外一个子系统发生了异常，服务消费者就应该采用统一的方式，判断这类异常是否能被容错，如果可以进行容错处理，那么就不需要抛出异常，如果处理不了，那就抛出异常表明，消费者使用服务时发生了错误。
包装异常，当消费者使用服务提供者发生的异常时，消费者应该使用其特定的异常对低层次的异常进行包装，而不是将低层次的异常直接抛向更高的层次，这样可以避免顶层的那些应用面对N种可能的异常情况，便于架构的统一处理。
李志强 说: 谢老师回答一下我的问题，谢谢
Rainbow! 说: 呵呵,不好意思
Rainbow! 说: 我们一般是把一些最稳定的user case确定后，进行分析、设计、开发、测试集成
Rainbow! 说: 这个过程肯定是一个迭代过程
Rainbow! 说: 而你说同时再考虑一些相对复杂、变化的需求，我是这么理解的
Rainbow! 说: 可以看成是上面迭代过程中需要考虑的一个环节
Rainbow! 说: 也可以考虑成是一个独立的迭代过程
主持人 说: 同意
Rainbow! 说: 对于后者来说，我个人理解，就是先易后难
主持人 说: 呵呵
Rainbow! 说: 呵呵
李志强 说: 谢谢
主持人 说: 好的,时间差不多了
weining45@126.com 说: 谢老师，我还有一个问题没有回答：架构的集成是在什么时候？
主持人 说: 好,等等
Rainbow! 说: 呵呵，集成应该在每一个迭代周期末期进行
Rainbow! 说: 持续集成
weining45@126.com (E-mail Address Not Verified) 说: 先集成再验证？
Rainbow! 说: 恩
Rainbow! 说: 集成应该是验证的一部分，这个是我个人的观点
Rainbow! 说: 架构集成不可能一蹴而就，架构集成是一个持续化的过程，是一个迭代的过程。当然现代架构集成，前提还是依赖于子系统的划分，以及明确的系统间交互接口的定义。在每个开发的迭代周期中，需要确定这些子系统的集成点，这个集成点指的是模块功能的完成程度，以及模块之间的交互关系的确立。在完成一个集成迭代后，还需要对这些集成点的状态进行跟踪，确定这个集成迭代的周期是否满足了预期的集成效果，然后再规划下一迭代周期。每次集成后，集成会引起系统一个重新的认识，在规划下一次迭代时，可以对系统有针对性地进行重构。
weining45@126.com (E-mail Address Not Verified) 说: 还想知道集成的方法，时间差不多就算了，谢谢你，谢老师
Rainbow! 说: 呵呵
主持人 说: 好的,
Rainbow! 说: 一般而言，都是划分集成点
Rainbow! 说: 说白了，集成就是将不同的组件整合起来
Rainbow! 说: 将单元测试变成
Rainbow! 说: 集成测试
weining45@126.com (E-mail Address Not Verified) 说: 集成点是功能的完成程度，要功能完成了才能集成？
Rainbow! 说: 将原先预定一的Input Parameter和Expected Result变成组件之间交互的输入和输出
Rainbow! 说: 不一定
Rainbow! 说: 可以参用mocker的方式，来完成对未完成功能的模拟
weining45@126.com (E-mail Address Not Verified) 说: 哦
李志强 说: 请教一点，讨论内容可不可以传播，不涉及版权吧，呵呵
主持人 说: 可以
主持人 说: 欢迎转发
主持人 说: 谢老师的可以么?
李志强 说: 希望其他同事和朋友也能共享谢老师的经验
Rainbow! 说: 恩
Rainbow! 说: 没问题
Rainbow! 说: 欢迎
Rainbow! 说: 大家交流
主持人 说: 如果大家没有问题,今天就到这里了
主持人 说: 呵呵,同意么
主持人 说: 时间过了,已经
Rainbow! 说: 呵呵，谢谢大家给我一个交流的机会
weining45@126.com (E-mail Address Not Verified) 说: 好的
李志强 说: 谢老师和主持人辛苦了
李志强 说: 谢谢！
主持人 说: 感谢 谢老师在百忙中来这里和大家分享宝贵的经验
weining45@126.com (E-mail Address Not Verified) 说: 谢谢 谢老师教了我们这么多知识！
主持人 说: 也感谢大家的参与
gooder (E-mail Address Not Verified) 说: 谢谢谢老师
wate 说: 感谢 谢老师和 主持人
wate 说: 学了不少东西
主持人 说: www.uml.org.cn会定期举行在线和现场交流，请多留意我们的网站
Rainbow! 说: 好的
主持人 说: 今天就到这里了，可以撤了
主持人 说: 呵呵，谢老师，您可以先走
Rainbow! 说: 好的，谢谢
李志强 说: 再见了，吃饭去喽
主持人 说: 88
主持人 说: 都饿肚子呢
主持人 说: 呵呵
Rainbow! 说: 88
Rainbow! 说: 是啊是啊
weining45@126.com (E-mail Address Not Verified) 说: 肚子都饿扁了……
weining45@126.com (E-mail Address Not Verified) 说: 88
主持人 说: 呵呵，更苗条了
weining45@126.com (E-mail Address Not Verified) 说: 呵呵，顺便问一句，近期还有在线交流吗？
wate 说: 吃饭去了
主持人 说: 有
主持人 说: 1-2个月一次
weining45@126.com (E-mail Address Not Verified) 说: 关于什么的？
weining45@126.com (E-mail Address Not Verified) 说: 有没有关于测试的？
主持人 说: 正在计划中，很可能是测试或者 开发过程的
主持人 说: 留意网站公告吧，或者月刊邮件