几种常用层间交互模式

一般系统可划分为三个层次：表现层，领域层，数据源层。通常还可以将领域层提取出服务层来。

根据不同的应用场景，不同的架构设计将会有不同的层间交互形式。

常见的有如下几种：

模式一
UI->Domain->Data Source
此模式是很典型的一种交互方式，简单纯粹，上层依赖于下层，没有跨层调用。

模式二
UI->Domain->Data Source
UI->Data Source
此模式是不太纯粹的交互方式，允许跨层调用，但在实践中运行良好。

模式三
UI->Domain<-Data Source
此模式是典型的采用依赖倒置原则的交互方式，Domain将不再依赖于Data Source，实现方式通常是在Domain定义Data Source接口。

模式四
UI->Service->Domain->Data Source
此模式是引入服务层之后的典型交互方式，类似于模式一。

模式五
UI->Service->Domain->Data Source
Service->Data Source
此模式类似于模式二。

模式六
UI->Service->Domain<-Data Source
此模式类似于模式三。

模式七
UI->Service->Domain<-Data Source
Service->Data Source
此种模式是模式二和三引入服务层后演化来的。

还有很多其他的模式和变种，在此仅列出比较常见的一些。

以上各种模式没有好坏，高低之分。只有适不适用的问题。
每种模式都有它的运用场景，要根据具体情况具体分析。

模式3或者7可能是最适合于一些大型系统的.

在我看来，分层的目标是减少依赖。不过如果一定要总结各层的模式我觉得是很不现实的，我个人从来不依赖模式，但是强调变与不变之间的契约。如果不变的部分作为各层间的会话基础，层与层之间完全没有依赖的必要。Spring不就已经实现了吗？
关于这不变的部分，如果太小我们称为API或者框架(Framework)；如果不大不小我们称为架构(Architecture)；如果再大一些我们称为平台(Platform)。
我们为什么要受模式约束来捆住自己？

窃以为一切都应该依赖于业务逻辑。业务逻辑是中心， 至于是否能做到，从多大程度上做到，就受当前的技术，以及开发者的水平影响。

模式只是给你提出一些前人的建议， 在你领悟其中的内涵之后是可以摆脱模式的束缚。 但是在你尚未领悟之前， 模式绝对是你值得参考和研究的对象。