《2022年系统架构设计-如何设计架构收集 .pdf》由会员分享，可在线阅读，更多相关《2022年系统架构设计-如何设计架构收集 .pdf（8页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、系统架构设计:如何设计架构?疯狂代码 http:/ Part 1 层 层(layer)这个概念在计算机领域是非常了不得个概念计算机本身就体现了种层概念:系统层、设备驱动层、操作系统层、CPU 指令集每个层都负责自己职责网络同样也是层概念最著名OSI 7层协议 层到了软件 Software 领域也样好用为什么呢？我们看看使用层技术有什么好处:你使用层但是不需要去了解层实现细节 可以使用另种技术来改变基础层而不会影响上面层应用 可以减少区别层的间依赖 容易制定出层标准 底下层可以用来建立顶上层多项服务 当然层也有弱点:层不可能封装所有功能旦有功能变动势必要波及所有层 效率降低 当然层最难个问题还是
2、各个层都有些什么以及要承担何种责任 典型 3 层结构 3 层结构估计大家都很熟悉了就是表示(presentation)层,领域(do)层,以及基础架构(infrastructure)层 表示层逻辑主要处理用户和软件Software 交互现在最流行莫过于视窗图形界面(wimp)和基于 html 界面了表示层主要职责就是为用户提供信息以及把用户指令翻译传送给业务层和基础架构层 基础架构层逻辑包括处理和其他系统通信代表系统执行任务例如数据库系统交互和其他应用系统交互等大多数信息系统这个层最大逻辑就是存储持久数据 还有个就是领域层逻辑有时也被叫做业务逻辑它包括输入和存储数据计算验证表示层来数据根据表示
3、层指令指派个基础架构层逻辑 名师资料总结-精品资料欢迎下载-名师精心整理-第 1 页，共 8 页 -领域逻辑中人们总是搞不清楚什么事领域逻辑什么是其它逻辑例如个销售系统中有这样个逻辑:如果本月销售量比上个月增长 10就要用红色标记要实现这个功能你可能会把逻辑放在表示层中比较两个月数字如果超出10就标记为红色 这样做你就把领域逻辑放到了表示层中了要分离这两个层你应该现在领域层中提供个思路方法用来比较销售数字增长这个思路方法比较两个月数字并返回boolean类型表示层则简单该思路方法如果返回true 则标记为红色 例子 层技术不存在说永恒窍门技巧如何使用都要看具体情况才能够决定下面我就列出了 3
4、个例子:例子 1:个电子商务系统要求能够同时处理大量用户请求用户范围遍及全球而且数字还在不断增长但是领域逻辑很简单无非是订单处理以及和库存系统连接部分这就要求我们1、表示层要友好能够适应最广泛用户因此采用html 技术；2、支持分布式处理以胜任同时几千访问；3、考虑未来升级 例子 2:个租借系统系统用户少多但是领域逻辑很复杂这就要求我们制作个领域逻辑非常复杂系统另外还要给他们用户提供个方便输入界面这样wimp是个不错选择 例子 3:简单系统非常简单用户少、逻辑少但是也不是没有问题简单意味着要快速交付并且还要充分考虑日后升级需求在不断增加的中 何时分层 这样 3 个例子就要求我们不能够概而论解决
5、问题而是应该针对问题具体情况制定具体解决思路方法这 3 个例子比较典型 第 2 个例子中可能需要严格分成 3 个层次而且可能还要加上另外中介(mediating)层例3则不需要如果你要做仅是查看数据那仅需要几个server 页面来放置所有逻辑就可以了 我般会把表示层和领域层/基础架构层分开除非领域层/基础架构层非常简单而我又可以使用工具来轻易绑定这些层这种两层架构最好例子就是在VB、PB 环境中很容易就可以构建出个基于SQL 数据库 windows界面系统这样表示层和基础架构层非常致但是旦验证和计算变得复杂起来这种方式就存在先天缺陷了 很多时候领域层和基础架构层看起来非常类似这时候其实是可以把
6、它们放在起可是当领域层业务逻辑和名师资料总结-精品资料欢迎下载-名师精心整理-第 2 页，共 8 页 -基础架构层组织方式开始区别时候你就需要分开 2 者 更多层模式 3 层架构是最为通用尤其是对IS系统其它架构也有但是并不适用于任何情况 第种是 Brown model Brown et al它有 5 个层:表示层(Presentation)控制/中介层(Controller/Mediator)领域层(Do),数据映射层(Data Mapping),和数据源层(Data Source)它其实就是在 3 层架构种增加了两个中间层控制/中介层位于表示层和领域层的间数据映射层位于领域层和基础架构层的
7、间 表示层和领域层中介层我们通常称的为表示-领域中介层是个常用分层思路方法通常针对些非可视Control 控件例如为特定表示层组织信息格式在区别窗口间导航处理交易边界提供Serverfacade 接口(具体实现原理见设计模式)最大危险就是些领域逻辑被放到这个层里影响到其它表示层 我常常发现把行为分配给表示层是有好处这可以简化问题但表示层模型会比较复杂所以把这些行为放到非可视化对象中并提取出个表示-领域中介层还是值得 Brown ISA 表示层 表示层 控制/中介层 表示-领域中介层 领域层 领域层 数据映射层 数据库交互模式中 Database Mapper 数据源层 基础架构层 领域层和基础
8、架构层的间中介层属于本书中提到Database Mapper模式是 3 种领域层到数据连接办法的和表示-领域中介层眼有时候有用但不是所有时候都有用 还有个好分层架构是J2EE 架构这方面讨论可以见J2EE 核心模式书他分层是客户层(Client)表示层(Presentation)业务层(Business)整合层(Integration)资源层(Resource)差别如下图:J2EE 核心 ISA 名师资料总结-精品资料欢迎下载-名师精心整理-第 3 页，共 8 页 -客户层 运行在客户机上表示层 表示层 运行在服务器上表示层 业务层 领域层 整合层 基础架构层 资源层 基础架构层通信外部数据
9、微软 DNA 架构定义了 3 个层:表示层(presentation)业务层(business)和数据存储层(data access)这和我架构相似但是在数据传递方式上还有很大区别在微软DNA 中各层操作都基于数据存储层传出SQL 查询结果集这样话实际上是增加了表示层和业务层同数据存储层的间耦合度 DNA 记录集在层的间动作类似于Data TransferObject Part 2 组织领域逻辑 要组织基于层系统首要是如何组织领域逻辑领域逻辑组织有好几种模式但其中最重要莫过于两种思路方法:Transation Script和Do Model选定了其中种其它都容易决定不过这两者的间并没有条明显分
10、界线所以如何选取也是门大学问般来说我们认为领域逻辑比较复杂系统可以采用Do Model Transation Script就是对表示层用户输入处理包括验证和计算存储其它系统操作把数据回传给表示层用户个动作表示个这个可以是script也可以是 transation也可以是几个子在例子 1中检验在购物车中增加本书显示递送状态都可以是个 Transation Script Do Model是要建立对应领域名词模型例如例1中书、购物车等检验、计算等处理都放到领域模型中 Transation Script属于结构性思维 Do Model属于OO 思维Do Model比较难使用旦习惯你能够组织更复杂逻辑你
11、思想会更 OO 到时候即使是小系统你也会自然使用Do Model了 但如何抉择呢？如果逻辑复杂那肯定用Do Model:如果只需要存取数据库那Transation Script会好些但是需求是在不断进化你很难保证以后需求还会如此简单如果你团队(Team)不善于使用 Do Model那你需要权衡下投入产出比另外即使是Transation Script也可以做到把逻辑和基础架构分开你可以使用Gateway 对例 2毫无疑问要使用 Do Model对例1就需要权衡了而对于例 3你很难说它将来会不会像例2那样你现在可名师资料总结-精品资料欢迎下载-名师精心整理-第 4 页，共 8 页 -以使用 Tra
12、nsation Script但未来你可能要使用 Do Model所以说架构决策是至关紧要 除了这两种模式还有其它中庸模式Use Case Controller就是处于两者的间只有和单个用例相关业务逻辑才放到对象中所以大致上他们还是在使用Transation Script而Do Model只是Database Gateway组集合而已我不太用这种模式 Table Module 是另个中庸模式很多 GUI环境依托于 SQL 查询返回结果你可以建立内存中对象来把GUI和数据库分开来为每个表写个模块因此每行都需要关键字变量来识别每个例子 Table Module 适用于很多组件构建于个通用关系型数据库
13、的上而且领域逻辑不太复杂情况MicrosoftCOM 环境以及它带 ADO.NET.NET环境都适合使用这种模式而对于Java就不太适用了 领域逻辑个问题是领域对象非常臃肿对象行为太多了类也就太大了它必须是个超集这就要考虑哪些行为是通用哪些不是可以由其它类来处理可能是Use Case Controller也可能是表示层 还有个问题复制他会导致复杂和不致这比臃肿危害更大所以宁可臃肿也不要复制等到臃肿为害时再处理它吧 选择个地方运行领域逻辑 我们精力集中在逻辑层上领域逻辑要么运行在Client 上要么运行在 Server 上 比较简单做法是全部集中在Server 上这样你需要使用 html 前端以
14、及 web server 这样做好处是升级和维护都非常简单你也不用考虑桌面平台和Server 同步问题也不用考虑桌面平台其它软件Software 兼容问题 运行在 Client 适合于要求快速反应和没有联网情况在Server 端逻辑用户个再小请求也需要信息从Client 到Server 绕圈反应速度必然慢再说网络覆盖程度也不是说达到了100 对于各个层来说又是如何样呢？基础架构层:般都是在 Server 啦不过有时候也会把数据复制到合适高性能桌面机但这是就要考虑同步问题了 表示层在何处运行取决于用户界面设计个Windows 界面只能在 Client 运行而个 Web 界面就是在 Server
15、运行也有特别例子在桌面机上运行web server 例如X Server 但这种情况少多 在例 1中没有更多选择了只能选在Server 端因此你每个 bit 都会绕个大圈子为了提高效率尽量使用些纯名师资料总结-精品资料欢迎下载-名师精心整理-第 5 页，共 8 页 -html 脚本 人们选用 Windows 界面原因主要就是需要执行些非常复杂任务需要个合适应用而web GUI则无法胜任这就是例2做法不过人们应该会渐渐适应web GUI而web GUI功能也会越来越强大 剩下是领域逻辑你可以全部放在Server 也可以全部放在 Client 或是两边都放 如果是在 Client 端你可以考虑全部
16、逻辑都放在Client 端这样至少保证所有逻辑都在个地方而把web server 移至Client 是可以解决没有联网问题但对反应时间不会有多大帮助你还是可以把逻辑和表示层分离开来当然你需要额外升级和维护工作 在 Client 和Server 端都具有逻辑并不是个好处理办法但是对于那些仅有些领域逻辑情况是适用有个小窍门把那些和系统其它部分没有联系逻辑封装起来 领域逻辑接口 你 Server 上有些领域逻辑要和 Client 通信你应该有什么样接口呢？要么是个http 接口要么是个 OO 接口 http 接口适用于 web browser就是说你要选择个 html 表示层最近新技术就是 web
17、service 通过基于 http、特别是 XML 进行通信 XML 有几个好处:通信量大结构好仅需次回路这样远程开销就小了同时XML 还是个标准支持平台异构 XML 又是基于文本能够通过防火墙 虽然 XML 有那么多好处不过个 OO 接口还是有它价值 hhtp接口不明显不容易看清楚数据是如何处理而OO 接口思路方法带有变量和名字容易看出处理过程当然它无法通过防火墙但可以提供安全和事务的类控制 最好还是取 2 者所长 OO 接口在下 http 接口在上但这样做就会使得实现机制非常复杂 Part 3 组织web Server 很多使用 html 方式人并不能真正理解这种方式优点我们有各种各样好用
18、工具但是却搞到让难以维护 在 web server 上组织方式大致可以分为两种:脚本和 server page 脚本方式就是个用和思路方法来处理http 例如CGI脚本和 java servlet它和普通并没有什么两样它从web 页面上获得 html 形态数据有时候还要做些表达式匹配这正是perl 能够成为 CGI脚本常用语言原因而 javaservelet 则是把这种分析留给员但它允许员通过关键字接口来访问信息这样就会少些表达式判断这种格式webserver 输出是另种 html 称为response可以通过流数据来操作 名师资料总结-精品资料欢迎下载-名师精心整理-第 6 页，共 8 页
19、-糟糕是流数据是非常麻烦因此就导致了server page 产生例如 PHPASPJSP server page 方式适合回应(response)处理比较简单情况例如“显示歌曲明细”但是你决策取决于输入时候就会比较杂乱例如“通俗和摇滚显示格式区别”脚步擅长于处理用户交互server page 擅长于处理格式化回应信息所以很自然就会采用脚本处理请求交互使用server page 处理回应格式化这其实就是著名MVC(Model View Controller)模式中 view/controller处理 _disibledevent=get_larger(this)/web server 端MVC
20、工作流程示意图 应用 Model View Controller模式首要点就是模型要和web 服务完全分离开来使用 Transaction Script或Do Model模式来封装处理流程 接下来我们就把剩余模式归入两类模式中:属于Controller模式以及属于 View模式 View模式 View这边有 3 种模式:Transform ViewTemplate View和Two Step ViewTransform View 和TemplateView处理只有步将领域数据转换为htmlTwo Step View 要经过两步处理第步把领域数据转换为逻辑表示形式第2步把逻辑表示转换为 html
21、 两步处理好处是可以将逻辑集中于处如果只有步变化发生时你就需要修改每个屏幕但这需要你有个很好逻辑屏幕结构如果个 web 应用有很多前端用户时两步处理就特别好用例如航空订票系统使用区别第 2 步处理就可以获得区别逻辑屏幕 使用单步思路方法有两个可选模式:Template ViewTransform ViewTemplate View其时就是把代码嵌入到html 页面中就像现在 server page 技术如 ASPPHPJSP这种模式灵活强大但显得杂乱无章如果你能够把逻辑逻辑在页面结构的外进行很好组织这种模式还是有它优点 Transform View 使用翻译方式例如 XSLT 如果你领域数据是用 XML 处理那这种模式就特别好用 Controller模式 Controller有两种模式般我们会根据动作来决定项控制动作可能是个按钮或链接所这种模式就是Action名师资料总结-精品资料欢迎下载-名师精心整理-第 7 页，共 8 页 -Controller模式 Front Controller更进步它把 http 请求处理和处理逻辑分离开来般是只有个web handle 来处理所有请求你所有http 请求处理都由个对象来负责你改变动作结构影响就会降到最小 2009-1-9 15:17:55 疯狂代码 http:/ 8 页，共 8 页 -