8.企业应用架构模式 --- 通盘考虑

	极限编程，持续集成，测试驱动开发，重构。

1.从领域层开始
	三种模式最简单的是事务脚本模式。比较符合大多数人的习惯。它将每种系统事务的逻辑很好的封装在功能完善的脚本中，而且比较适合于在关系数据库之上构建。
  它的主要问题是对复杂业务逻辑的支持不够，尤其是不善于处理重复代码。
  	最复杂的是领域模型模式。缺点是难以学会使用领域模型。第二个缺点就是它与数据库的连接。
  	表模块模式是这2个极端之间一个比较好的折中。在处理领域逻辑上，它比事务脚本强。虽然它在处理复杂领域逻辑上不如领域模型，但是对于关系数据库和其他一些东西
  而言，它还是游刃有余的。

2.深入到数据源层
	一旦选择了领域层，你就必须决定如何与数据源相联系。这是的选择是以领域层选择为基础的，所以由该选择驱动。

	1.事务脚本的数据源
		最简单的事务脚本包含其自身的数据库逻辑，避免这样做。分离数据库，使得领域逻辑和数据源逻辑这两部分界限划分变得有意义，即使是最简单的应用，也要分离。
	  此时，可选择的数据库模式包括行数据入口和表数据入口。
	  	两者选哪个，很大程度上取决于实现平台的方便以及系统未来的发展方向。在行数据入口中，每个记录都通过显式的接口读入到一个对象中。在表数据入口，程序员
	  可以少些一些代码，因为他不需要写那么多存取器代码就可以读取数据，但是编程接口却是相对隐式的，这些接口依靠对记录集的访问(类似于映射)。
	  	最关键的决策在于所用开发平台的其余方面。如果所用的平台包含很多支持记录集的工具，特别是UI工具和事务性的断接记录集，则选择的天平就偏向表数据入口。
	  	在这种情况下，通常无需其他的OR映射模式。结构映射问题在很大程度上得到缓解，因为内存数据结构与数据库结构间的映射高度一致。也可以考虑工作单元，但
	  一般来说，在脚本中跟踪变化的部分很容易。在这里，无需关心大多数并发问题，因为脚本基本上对应一个系统事务。因此，可以将整个脚本封装在单个事务中。异常
	  一般发生在一个请求将数据读取出来编辑，而下一个请求视图对变化进行保存的情况下。在这种情况下，一般使用乐观离线锁。

	2.表模块的数据源
		选择表模块最主要的原因是有一个好的记录集框架。此时，就需要一个与记录集配合良好的数据库映射模式，就是表数据入口。使用了这个模式后，在数据源层几乎不需要
	  再加其他什么功能。在比较理想的情况下，记录集中都内置了某种形式的并发控制机制，这就使得它成为工作单元，从而进一步降低了开销。

	3.领域层的数据源
		领域模型的最大缺点是它与数据库的连接很复杂。而这个复杂程度实际上取决于模式的复杂程度。
		如果领域模型相当简单，例如只有十几个与数据库相关的类，则活动记录就可以了。如果希望耦合更加松一点，则可以使用表数据入口或行数据入口。随着复杂度的进一步
	  增加，可以考虑使用数据映射器，这种方法确保领域模型尽可能与其他各层互相独立。但是数据映射器也是实现起来最复杂的一种模式。

3.表现层
	表现层在很多方面都独立于其下层的选择。你首先会问，是提供胖客户用户界面，还是html浏览器界面？胖客户界面的效果更好，但是你必须为此付出更多的代价，即对客户端程序
  进行控制和部署管理。如果情况允许，尽可能使用html浏览器方式。实在不行，再用胖客户用户界面。
  	如果你走html路线，就必须决定如何组织你的应用。建议是使用模式---视图---控制器 作为设计基础。如果确定使用该模式，则剩下来的就只有两个决定:一个是控制器，一个是
  视图。
  	关于视图的两个选择：模板视图和转换视图。这主要取决于开发组编程时使用的是服务器页面还是XSLT。尽管我非常欣赏转换视图额外提供的测试能力，但模板视图还是略占上风。
  如果你开发的是一个由多种表现形式的站点，请使用考虑两步视图。
  	如何与下层通信取决于两个因素：一个是待通信的是哪一层，另一个是它们是否处于同一个运行的进程。如果可能，建议将所有的东西都运行在一个进程中。这样就不用担心低效的
  进程间通信。如果实在无法再一个进程中完成，可以将领域逻辑层用远程外观包装，然后使用数据传输对象实现与web服务器的通信。		

5.其他分层方式
	Brown :					Fowler
		1.表现层  			表现层
		2.控制层/中介层	    表现层
		3.领域层 			领域层
		4.数据映射层  		数据源层
		5.数据源层 			数据源层

		应用控制器(模式)是表现层与领域层之间的中介层，而数据映射器则是数据源层与领域层之间的中介层。

	Core J2EE :					Fowler
		1.客户层  			运行于客户端的表现层(如，胖客户系统)
		2.表现层	    	    运行于服务端的表现层(如,http处理程序，服务器页面)
		3.业务层 			领域层
		4.集成层  			数据源层
		5.资源层 			需要与数据源层通信的外部资源

		业务层和集成层存在简单的对应关系，资源层包含了集成层需要连接到的外部服务。主要的区别在于它将表现层分成了客户端部分(客户层)和服务端部分(表现层)。这是非常有用的
	  隔离方法，但同样，这种分层方式不是任何时候都需要。

	Microsoft DNA 分层模型 :	Fowler
		1.表现层	    	    表现层
		2.业务层 			领域层
		3.数据访问层			数据源层

		DNA 中的记录集实际上充当一种各层之间的数据传输对象。业务层能够根据自己的方式修改记录集，甚至可以自己创建一个新的记录集(少数情况)。虽然这种形式的通信方式有点笨拙，
	  但它的好处在于允许表现层使用一些数据敏感的GUI控件，这些控件甚至可以以创作由业务层修改了的数据。
	  	这种情况下，领域层通常组织成表模块形式，而数据源层使用表数据入口。

	Marinescu 分层模型 :		Fowler
		1.表现层	    	    表现层
		2.应用层 			表现层(应用控制器)
		3.服务层				领域层(服务层)
		4.领域层 			领域层(领域模型)
		5.持久层 			数据源层

		将服务层从领域层剥离出来的一个原因，源于将工作流逻辑从纯粹领域逻辑中的剥离。服务层所包含的逻辑一般都特定于某个用例，并与其他一些基础设施互相通信，如消息机制。

	Nilsson 分层模型 :		Fowler
		1.顾客层    	    	表现层
		2.顾客帮助层 			表现层(应用控制器)
		3.应用层				领域层(服务层)
		4.领域层 			领域层(领域模型)
		5.持久访问层 			数据源层
		6.公共存储过程层  	数据源层(可能包含一些领域层)
		7.私有存储过程层 		数据源层(可能包含一些领域层)

		Nilsson 中使用了一种较复杂的分层模型。映射到这种模型有点复杂，这是因为Nilsson太广泛的使用存储过程，并且为了性能远远而鼓励在存储过程中使用领域逻辑。

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