《会议介绍》

主持人 (19:15:10) 说:
架构是个很大的话题，可谓仁者见仁，智者见智，一会欢迎深入讨论，欢迎独到见解

主持人 (19:18:02) 说:
谢峰，系统架构师，上海交通大学硕士。
有多年的J2EE开发和架构设计经验。从事过大型物流软件的架构设计，企业基础平台的设计和开发。目前主要工作是设计基于银行金融业务的企业级架构，和Business Intelligence的应用。
主要特长：面向对象设计与分析，设计模式, UML, J2EE各种技术的综合应用，
分布式计算模型，Richclient Internet Architecture(RIA)架构设计，Web2.0架构设 计,
企业级架构整合,商业智能。
著作：《分布式模型改进方案》《基于智能客户端的企业基础平台的设计》

主持人 说:
通过在线的方式交流关于《应用架构设计实践》的一些经验，并对先前发布的视频<<应用架构设计实践>>进行答疑，答疑范围包括但不限于本视频，参与讨论者可以提出自己在应用架构设计中的相关问题。本次交流适用于一切对架构设计与应用感兴趣的软件行业从业者。

way 说:
架构基线主要是什么，
Rainbow! 说:
架构基线是一个“小的、皮包骨架的”系统，是系统整个生命周期的开发准则，适用于所有的迭代周期
Rainbow! 说:
这个是他的概念，我用比较流行的方式解释
lanfairy 说:
领域建模应该是业务层面的吧
Rainbow! 说:
对
Rainbow! 说:
在我的理解中，架构基线在大部分情况下，应该是非功能性框架
lanfairy 说:
还是不太明白架构基线
Rainbow! 说:
比如我们常用的struts, spring,hibernate等等，这些构建的一个软件的基础结构，可以称为架构基线
Rainbow! 说:
其实可以这么理解，在没有基线的时候，比如，我们需要开发一个应用，可能我们就按照现有的工具，以及客户的定义，逐个开发
Rainbow! 说:
拿这种情况下，可能有一部分的功能，尤其是非功能性需求的那些模块，你开发人员A会自己实现一套，B也会实现一套
Rainbow! 说:
而其实现的效果都是一样的
Rainbow! 说:
那有了架构基线之后呢，我们就会把这些公用的功能进行抽取
Rainbow! 说:
抽取最后的结果就是形成了架构基线
Rainbow! 说:
而对于下次开发的时候，我就会和A和B说，你不用重复开发这个功能了，我们已经有了实现
Rainbow! 说:
其实如果从面向对象的概念来解释，也就是架构基线可以在整个软件开发的生命周期中都能被reuse
way 说:
哦
Rainbow! 说:
而从面向对象设计的角度而言，架构基线帮你完成了整个软件的通用性功能。
way 说:
业务架构和企业架构，技术架构，具体都指什么
Rainbow! 说:
业务架构
lanfairy 说:
到底是通用功能，还是通用的开发框架
Rainbow! 说:
也就是我们常说的Business Application Architecture，是对需求的描述，以及业务模型的定义，其中包括领域模型(Domain Object),业务流程模型(Business Process Model),系统参与者(Actor)
way 说:
我很少考虑业务架构和企业架构
Rainbow! 说:
企业架构：指的是在对一个企业的业务战略和流程理解基础之上，进行信息化的顶层设计，对企业现有的业务架构和技术架构进行有效的整合，形成灵活健壮的IT结构，构建的和谐IT环境
Rainbow! 说:
到底是通用功能，还是通用的开发框架
-〉是这么理解的，通用的开发框架实现了通用的功能
Rainbow! 说:
比如，分布式系统，我们在通用的开发框架中实现了基于RMI-IIOP的分布式通信
Rainbow! 说:
好的架构就可以使得开发人员无须关心具体的通信方式，而由通用的开发框架来帮你完成
Rainbow! 说:
或者再简单一点的例子，Spring就是一个通用性的开发框架，他帮你实现了AOP和IOC注入，这对于开发人员来说无须关心

主持人 说:
刚才有个问题：谢老师我想问一下，一般对于非功能性需求，我简单认为主要指的是性能要求，那么非功能性架构指的是？
Rainbow! 说:

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) 说:
前面提到技术架构包括系统结构的设计规范的定义，如何进行定义？定义些什么？
lanfairy 说:
性能的要求可能会影响整体的架构调整
Rainbow! 说:
这个可能就要视具体情况而定了，可以这么说，如果我来设计一个非功能性架构，遇到了你所提的这个问题，“针对不同的应用会有不同的要求”，我会采用Strategy的方式，抽取通用的非功能性行为，而针对不同应用使用不同的实现
Rainbow! 说:
前面提到技术架构包括系统结构的设计规范的定义，如何进行定义？定义些什么？
-〉〉
Rainbow! 说:
这个概念可以这么理解
Rainbow! 说:
我先说明一个简单的例子
good@uml.net.cn (E-mail Address Not Verified) 说:
如果设计一个架构，具体的行动过程是什么呢
Rainbow! 说:
非常简单，几乎所有的系统在实现时，都会遇到字符串处理问题，比如，判空，分割等等，可能没有技术架构时，我们都会自行按照我们的knowledge来实现，而有了技术架构后呢，我们会对这些字符串处理的行为进行提炼，提炼成StringUtilities对象，然后再具体的实施过程中，就规定必须使用StringUtilities来处理字符串，这其实就是一个最简单的设计规范的定义
Rainbow! 说:
那对于更高层次的定义，可以理解为基于整个架构开发的一个Guideline，比如对于分布式模型，表现层的对象不能直接实例化业务层的对象，或者说表现层和业务层的通讯必须基于框架提供的通信组件来完成

Rainbow! 说:
请教谢老师，对于一个500用户分布式系统，和一个10W用户的系统，在架构设计上应该注意哪些呢
赫赫，这个问题厉害
Rainbow! 说:
其实这种情况，我是这么理解的，我们不是万能的，在架构设计之初会考虑到今后各种可能的变化，而当遇到类是的需求变化时，就要考虑采用外围的方式来解决。
Rainbow! 说:
我只的外围
Rainbow! 说:
是说，在尽量不去修改原有架构的基础上
Rainbow! 说:
当然如果你说原来架构设计的，一塌糊涂，神仙也难就，想重头来过，那我也没话说，赫赫
Rainbow! 说:
对于你这个问题，一般而言，几种方式
Rainbow! 说:
一个地球人都知道，集群
Rainbow! 说:
还有一种，就是采用不同的缓存技术
Rainbow! 说:
不同策略的
Rainbow! 说:
比如对于一些不同层面实现那些不易变的数据缓存
Rainbow! 说:
或者按照策略实现分级缓存
way 说:
是啊
Rainbow! 说:
曾经我也有过类是问题
way 说:
集群，缓存
Rainbow! 说:
我们设计的基于Smart Client的分布式系统，在用户数到达一定程度的时候，发现速度急剧下降
Rainbow! 说:
后来才发现，其原因在于，很多业务数据处理，都需要Server端提供国家，城市，等地址信息，而这些信息又不是易变的
Rainbow! 说:
而且也比较大，后来，我们就利用Smrat Client技术的特点，将这些不易变的数据在Client进行缓存
Rainbow! 说:
速度得到明显改善
Rainbow! 说:
我这只是说明了一个简单的例子
Rainbow! 说:
对于复杂情况而言，还需要对现有架构的业务架构和技术架构进行分析，
lanfairy 说:
思路不错，谢谢谢老师，呵呵
Rainbow! 说:
对业务架构分析是否设计的合理，Business Sequence是否可以进行优化，比如通过Delegate Pattern来降低分布式的通讯，使用coarse-grained接口统一协调Business Process。
Rainbow! 说:
赫赫，谢谢
Rainbow! 说:
对于技术架构，分析就是考虑如何通过统一的方式降低各种层面交互的开销，比如采用数据压缩，或者缓存。同时也需要对已采用的缓存策略进行分析，分析其是否合理，是否符合应用的要求。比如一个对数据库更新操作非常频繁的系统，采用hibernate做持久层，如果使用了2级缓存，反而降低了持久层的性能。

Rainbow! 说:
谢老师，前面讨论先有用例，再进行子系统的划分，那么在分析了系统的用例之后，如何进行子系统的划分呢？子系统划分的原则是什么？
-〉〉
Rainbow! 说:
我主要归结于以下几点
Rainbow! 说:
分而自治：确定子系统的责任边界
面向服务：子系统交互面向接口，确定服务范围
协同规划：子系统定义需要有整体规划，划分时需要考虑多个子系统的协作关系，以及子系统组合后提供的高层次子系统的职责。

Rainbow! 说:
其中第一条非常重要
way 说:
具体说说？
Rainbow! 说:
Responsibility Boundary可以使整个软件系统结构化变得十分清晰
Rainbow! 说:
对于，每个子系统的设计和开发人员而言，通过明确的边界定义，他们可以清楚地认识到自己的职责，可以更好的focus在本系统的业务逻辑的实现上。
Rainbow! 说:
对于团队协作开发而言
way 说:
架构 设计好了，维护有什么原则么
way 说:
目前设计，总是预测不如变化快
way 说:
怎么把握呢
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! 说:
那么子系统的功能是越少越好吗？如何才能保证划分的合理？
Rainbow! 说:
-〉〉
weining45@126.com (E-mail Address Not Verified) 说:
例如底层的通信，我们可以划分一个专门用于建立连接的子系统，和一个专门准备传输数据的子系统，这样各子系统的责任边界非常明确，但是增加了各子系统之间传送的接口
Rainbow! 说:
当然事情都不能走极端化，这主要取决于在架构设计之初，对于整个需求定义的粒度划分
Rainbow! 说:
对于扩展性要求不高的系统，子系统可以划分的粗一点，没必要要求每个功能点都能被重用
way 说:
重用有什么原则
Rainbow! 说:
对于扩展性或者说弹性要求比较高的系统，比如那些大型的ERP产品，其面向的是一个特定行业的通用性软件，可能很多子系统在不同情况组合单独形成一个应用，这种情况下，就需要对这些功能进行细分，确立最小的可重用的粒度单位
Rainbow! 说:
按照粒度单位来划分子系统，比如物流软件里面的空运模块，海运模块等等
Rainbow! 说:
weining45@126.com (E-mail Address Not Verified) -〉〉
weining45@126.com (E-mail Address Not Verified) 说:
哦
Rainbow! 说:
我个人认为，针对不同系统而言，可以采用不同的设计方式，比如你提到的“准备传输数据的子系统”，其可扩展性要求不高
Rainbow! 说:
或者说通用性比较强，我就认为他可以不用单独成为一个子系统
Rainbow! 说:
还有说，数据传输和通信两者是绑定的存在的，那也没必要划分成两个子系统
Rainbow! 说:
因为他们组合完成了一个功能，按照职责划分的原则，可以将这两者结合作为一个子系togn
Rainbow! 说:
系统

Rainbow! 说:
重用其实就是对通用的行为的一种抽象以及提取
Rainbow! 说:
我个人认为，重用的原则划分，可以按照功能的通用性，逐一封装
Rainbow! 说:
还是具刚刚那个例子
lanfairy 说:
个人认为重用分成几个层面
Rainbow! 说:
比如字符串处理，日期处理，Collection处理，这些重用性很高
Rainbow! 说:
对，我同意
way 说:
哪些层面？
Rainbow! 说:
那我们可以对这类功能，进行抽取，提炼，形成一个层面的组件
Rainbow! 说:
恩，大家请看ppt第14个slide
Rainbow! 说:
一般而言，非功能性基础架构，可以看成是一个底层次的重用层面
Rainbow! 说:
他帮你完成了大部分非功能性要求，比如Trace，DB连接，数据库的CRUD操作，或者说分布式通信，Presentation Tier中的Widget， MVC数据绑定
Rainbow! 说:
这些公用的非功能性行为可以看成一个重用的层面
way 说:
不过看起来他们的面向的层面不同啊
Rainbow! 说:
当然这个层面中还可以细分，比如刚刚说的常用的字符串，日期处理等等，我不再细化
Rainbow! 说:
赫赫，我是从宏观上将重用的层面划分为非功能性，和功能性
way 说:
哦
Rainbow! 说:
对于功能性重用的划分
Rainbow! 说:
主要是对于各种业务模块共性的抽取，比如物流系统中，海运和空运他们的下订单的方式80%是一样的
uml@uml.net.cn （电子邮件地址未验证） 说:
【系统提示】有新用户 孤烟 - 雏菊世界 团结起来，藐视一切敌对者 加入群中
lanfairy 说:
其实单从字面理解很多都可以重用，架构、开发模式、模块、代码、包括泡MM方式，不知道说得对不对
Rainbow! 说:
那就可以对80%的功用特性就行抽取
Rainbow! 说:
形成可重用的业务组件
Rainbow! 说:
哈哈，对
Rainbow! 说:
有兴趣，这个比喻很恰当
way 说:
呵呵
Rainbow! 说:
有兴趣的话，大家也可以交流一下泡MM的方式，just a joke，言归正传