1.企业应用架构模式 --- 分层

企业应用架构模式 --- 分层
	在这种组织之下，上层使用了下层定义的服务，而下层对上层一无所知。另外，每一层对自己的上一层隐藏其下层的细节。
	分层的好处:
	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