企业应用架构模式 --- 分层在这种组织之下,上层使用了下层定义的服务,而下层对上层一无所知。另外,每一层对自己的上一层隐藏其下层的细节。分层的好处:1.在无需过多的了解其他层的基础上,可以将某一层作为一个有机整体来理解。2.可以替换某一层的具体实现,只要前后提供的服务相同即可。3.可以将层次间的依赖性减到最低4.分层有利于标准化工作5.一旦构建好了某一层,就可以用它为很多上层提供服务6.层次并不能封装所有的东西7.过多的层次会影响性能1.1 企业应用中层次的演化客户/服务器系统的出现,分层的概念更明显了。这样的系统是一种两个层次的系统:客户端包括用户界面和其他应用代码,服务器端通常是关系型数据库。因此,可以通过将控件拖拽到'设计区域'来建立界面,然后再使用属性表单把控件连接到后台数据库。如果应用仅仅包含关系数据的简单显示和修改,那么这种客户/服务器系统的工作方式非常合适。问题来自领域逻辑:如业务逻辑,验证,计算等。通常人们会把它们写在客户端,但是这样会很笨拙,并且往往把领域逻辑直接嵌入到客户界面。随着领域逻辑的不断复杂化,这些代码将越来越难用。另外一种办法是把这些领域逻辑放到数据库,作为存储过程。但是,存储过程只提供有限的结构化机制,这将再次导致笨拙的代码。在客户/服务器方式逐渐大众化的同时,面向对象方式开始崛起。面向对象为领域逻辑的问题找到了答案:转到三层架构的系统。在这种方式下,在表现层实现用户界面,在领域层实现领域逻辑,在数据源层存取数据。这种方式使得你可以将复杂的领域逻辑从界面代码中抽取出来,单独放到中间层,用对象加以建模组织。如果所有的领域逻辑都是写在'胖'客户中,则所有这些都必须在web界面重写。企业应用中层次的演化:C/S(领域逻辑放在客户端) -> 领域逻辑放到数据库,作为存储过程 -> 三层架构:表现层 + 领域层 + 数据源层1.2 三个基本层次表现层:提供服务,显示信息(例如在windows或HTML页面中,处理用户请求(鼠标点击,键盘敲击等),HTTP请求,命令行调用,批处理API)领域层:逻辑,系统中真正的核心数据源层:与数据库,消息系统,事务管理器及其它软件包通信表现逻辑处理用户与软件间的交互。可能简单到只是命令行或基于文本的菜单系统,但是当前的客户界面往往是功能完善的胖客户端图形界面,或者是基于HTML的浏览器。表现层的主要职责是向用户显示信息并把从用户那里获得的信息解释成领域层或数据源层的各种动作。数据源逻辑主要关注与其他系统的交互,这些系统将代表应用完成相关的任务。它们可以是事务监控器,其他应用,消息系统等。对于大多数企业应用来说,最主要的数据源逻辑就是数据库,它的主要责任就是存储持久数据。最后一部分就是领域逻辑,也称为业务逻辑。它就是应用必须做的所有的领域相关的工作:包括根据输入数据或已有数据进行计算,从对表现层输入的数据进行验证,以及根据表现层接收的命令来确定调度哪个数据源逻辑。有时候,层次组织成领域层对表现层完全隐藏了数据源层。但更多的时候,是表现层直接对数据存储进行操作。虽然这样做并不纯粹,但是在实践中往往运行良好。表现层可能解释来自用户的命令,通过数据源层将相关数据从数据库中提取出来,然后让领域逻辑层向用户显示相关数据之前先处理这些相关数据。如果某个应用不仅要支持用户通过盘客户端界面访问,还要支持用户通过命令行形式访问,则它需要两个表现层:一个支持胖客户端界面,另一个支持命令行。对于不同的数据库,通常也需要多个数据源组件。即便是领域逻辑,也有可能被分割成互相独立的不同部分,特定的数据源包只能由特定的领域包使用。为别人提供服务的接口与使用别人服务的接口存在较大的区别,需要明确区分。这就是表现层和数据源层相对核心的本质差别。表现层是系统对外提供服务的外部接口,不管外面是复杂的人类还是一个简单的远程程序。数据源层是系统使用外部服务的接口。这样区分的好处是:客户的不同将改变你对服务的看法。每个企业应用,尽管我们能够区分出其中的主要表现层,领域层和数据源层,但是具体如何分离要取决于应用的复杂程度。从数据库中读取数据并把它显示在web页面上的简单脚本,可能全部在一个过程中。这里可以把每个层的行为放到三个不同的子程序中。一旦系统再复杂一点,就可以将三个层次的工作分解成不同的类。如果复杂度继续增加,则把类分配到不同的包中。总体的建议是根据不同的问题,选择一种合适的分离方式,但是切记一定要进行某种形式的分离----至少在子程序级别。伴随着分离,还有一条关于依赖性的普遍原则:领域层和数据源层绝对不要依赖于表现层。也就是说,在领域层和数据源层的代码中,不要出现调用表现层的代码情况。这条规则将简化在相同基础上替换表现层的代价,也使得表现层的修改所带来的连锁反应尽可能小。领域层与数据源层的关系更复杂,其取决于数据源层的架构模式。使用领域逻辑时,其中最困难的部分就是区分什么是领域逻辑,什么是其他逻辑。一个不太正规的测试办法是:假想向系统中增加一个完全不同的新层,例如为web应用增加一个命令行界面。如果在这个过程中,发现需要重复实现某些功能,则说明可能有一些本应该在领域层实现的逻辑,现在在表现层实现了。类似的,你可以想象,将后台数据库更换成xml文件格式,看看情况如何?1.3 为各层选择运行环境对于大多数信息系统来说,主要的决定就是在哪里运行处理工作,是在客户机上,还是在台式机上,又或者是在服务器上?通常,最简单的情况是将所有的东西都运行在服务器上。在这种情况下,一个使用web浏览器的html前端是一个好办法。这样做最大的好处是所有的东西都在有限的环境内,很容易修改维护。无需考虑将它们分发到不同的客户端并维护与服务器的同步等问题。也不必考虑与客户机上其他软件的兼容性问题。在客户机上运行应用程序的好处是系统的响应性好,或者在网络断开的情况下也能正常的工作。任何运行的服务器上的逻辑响应客户请求时,都需要一个来回的通信开销。如果用户仅仅是为了试试系统的即使反馈,这个通信来回也无法避免。它还需要在网络连接保持的状态下运行。数据源层一般都是运行在服务器上。例外的情况是:当需要断开操作时,可以将服务器的功能复制到一台功能强大的客户机上。在这种情况下,在离线的客户机上对数据源的任何修改,都需要同步到服务器上。在何处运行表现层主要取决于用户界面的种类。如果运行的是一个胖客户,则意味着表现层运行在客户端。如果运行的是一个web页面,则意味着表现层运行在服务器端。即使非常简单的胖客户系统,也会遇到维护客户端一致性以及避免各种软件不兼容等问题。人们希望有胖客户表现层的主要原因是:有些任务对于用户而言太复杂了,为了有一个可用的应用系统,它们的需要超出了web gui 的能力。当然,人们已经在逐渐习惯采用使web前端更可用的各种方法,这些方法减少了对胖客户方式的需求。因此,我非常赞同只要有可能就用web表现方式,只有在必须的情况下才使用胖客户方式。剩下来的就是领域逻辑了。领域逻辑可以全都运行于服务器端,也可以全部运行于客户端,也可以一分为二。再有,全部运行在服务器端有助于系统维护,向客户端转移是为了响应是爱你以及断接使用的需要。如果你必须在客户端运行某个逻辑,你可以考虑将所有的逻辑运行在客户端---这样至少保证了相关的东西都在一起。这样,胖客户端和web服务器联合部署在客户机上,对响应性的改性不会太大,但是它可以作为一种处理断接操作的办法。在这种情况下,可以通过不同的模块将领域逻辑与表现层分开,可以使用事务脚本或领域模型。将所有的领域逻辑放在客户端的问题是升级和维护代价高。将领域逻辑分隔在客户端和服务器端,应该是最差的选择,因为这样做无法确定任意一块逻辑在哪里。采用这种办法的主要原因是:只有一小部分领域逻辑需要在客户端完成。其中的诀窍在于将这一部分独立出来称为自包含的模块,使得它不依赖于系统的任意其他部分。这样,就可以在客户端或服务器运行它了。一旦选择了处理节点,接下来就应该尽可能使所有代码保持在单一进程内完成。除非不得已,否则不啊哟把层次放在多个进程中完成。因为那样做不但损失性能,而且增加复杂性。因为必须增加类似下面的模式,如远程外观和数据传输对象。

https://juejin.im/post/5c4880e6518825260d7eea64

1.企业应用架构模式 --- 分层相关推荐

  1. 软件开发大师谈企业应用架构模式

    <企业应用架构模式(英文版)> --作者:Martin Fowler 多年来,Martin Fowler --这位享誉世界的软件开发大师--见证了许多企业级应用项目.这些项目通常都包含相似 ...

  2. 企业应用架构模式-30天阅读计划

    构建计算机系统并非易事.随着系统复杂性的增大,构建相应软件的难度将呈指数增大. 同其他行业一样,我们只有在不断的学习中进步,从成功经验中学习,从失败教训中学习,才有望克服这些困难. 这本书的内容就是这 ...

  3. 《企业应用架构模式》30天阅读计划

    构建计算机系统并非易事.随着系统复杂性的增大,构建相应软件的难度将呈指数增大. 同其他行业一样,我们只有在不断的学习中进步,从成功经验中学习,从失败教训中学习,才有望克服这些困难. 这本书的内容就是这 ...

  4. 图书推荐5:《企业应用架构模式》

    文章目录 基本介绍 推荐理由 总结 延续 基本介绍 书名 企业应用架构模式 作者 (美)Martin Fower 译者 王怀民 周斌 出版社 机械工业出版社 出版时间 2004年12月 页数 363 ...

  5. [201004][企业应用架构模式][王怀民][周斌][译]

    [201004][企业应用架构模式][王怀民][周斌][译] 模式列表 引言 0.1 架构 0.2 企业应用 0.3 企业应用的种类 0.4 关于性能的考虑 0.5 模式 0.5.1 模式的结构 0. ...

  6. 企业应用架构模式笔记

    1 企业应用模式概述 1.1 企业应用的模式 企业应用领域要解决的问题在某些方面要比做一个工具软件.或者一个电信通信软件等复杂的得多,比如纷杂的企业数据,各具特色的业务规则,变化莫测的用户需求.因此企 ...

  7. 企业应用架构模式学习笔记

    1.概述 2.分层 表现逻辑处理用户与软件间的交互.表现层的主要职责是向用户显示信息并把从用户那里获取的信息解释成领域层或数据源层上的各种动作. 数据源逻辑主要关注与其他系统的交互,这些系统将代表应用 ...

  8. ddd 企业应用架构模式_灵魂拷问:用了DDD分包就是落地了领域驱动设计吗?谈谈DDD本质...

    学习DDD的时候,作为开发,我们更关心它在技术层面的东西,尤其体现在DDD的分包方式.编码技巧等方面. 自然的,我们不禁发问,用了DDD的分包,就是实践落地了DDD了么? 不卖关子,直接说答案,并不是 ...

  9. 以太网的分层架构_读《企业应用架构模式》记录-分层

    复杂软件系统中,分层理念使用最多,具体例子: 软件体系中, 从包含了操作系统调用的程序设计语言到设备驱动程序和CPU指令集再到芯片内部的各种逻辑门:网络互联中,FTP层架构在TCP上,TCP架构在IP ...

  10. 第八天-《企业应用架构模式》-通盘考虑

    思考三个方面的技术实践:持续集成.驱动测试开发和重构 1. 从领域层开始 1)事务脚本模式最简单,适合于在关系数据库之上构建:领域模型需要非常专业的技术,还有鱼数据库的连接:表模块模式折中,在.Net ...

最新文章

  1. Sep 26 09:22:41 ck01 kernel: Buffer I/O error on device sda2, logical block 2
  2. 高通camera驱动分析
  3. Spring Enable annotation – writing a custom Enable annotation
  4. 子元素的margin-top影响父元素原因和解决办法
  5. 光流 | 使用Horn-Schunck方法进行光流估计(附代码)
  6. 基于空间方法的图神经网络模型_用于时空图建模的图神经网络模型 Graph WaveNet | 课程上新...
  7. 在 OpenShift 4 上部署 Ansible Tower 环境
  8. 2018.1.30-31 开始racket,避免mutation,lazy evaluation
  9. 计算机统计大数据库,统计数据库
  10. python爬视频网站数据_Python爬虫:B站排行榜视频播放量,视频评论量等数据采集...
  11. P34-c++中的代码重用-03多重继承详细介绍
  12. php 获取月份的周数,PHP获取当前月份的周数只能使用php
  13. 区块链到底是不是骗局
  14. android 生成多个表单,Android根据word模板文档将表单数据生成word文档的方案整理...
  15. 如何使用burpsuite对网站进行暴力破解?
  16. 怎样用python生成中文字符画_如何利用Python实现图片转字符画详解
  17. 美国计算机加音乐专业,美国留学:原来这就是传说中炫酷到炸裂的电子音乐制作专业...
  18. 整理ORACLE表空间文件
  19. mysql语法太难记住了_MYSQL语法实例(仅学习)
  20. (仿微信Android)聊天+红包+直播+朋友圈源码发布了

热门文章

  1. SecureCRT的安装、介绍、简单操作
  2. x264 编码数配置
  3. 兄弟连教育分享:用CSS实现鼠标悬停提示的方法
  4. Hibernate缓存之初探
  5. 区块链、ICO,养肥的是开发者和一群黑客
  6. NIM(Network Installation Manager)使用一例(mksysb)
  7. 什么是生命,这取决于肝脏。——《调音师》影评
  8. MyBatis学习笔记(一) 概述
  9. 分段锁——ConcurrentHashMap
  10. C# System.Timers.Timers的用法在工控设备上位中的用法