域模型

本文转自http://www.playframework.cn/wiki/%E5%9F%9F%E6%A8%A1%E5%9E%8B

这里的介绍跟我以前的设想截然相反，我之前把与数据紧密相关的逻辑才放到Model中，其他复杂的逻辑就抽象到逻辑层，这是为了提高逻辑层的复用。现在看来可能不太好！

模型（Model）在Play应用中处于非常核心的地位，是应用对操作信息的特定域的表现形式。

      Martin fowler做了如下的定义:模型层负责表示业务概念，业务状况的信息及其规则。尽管保存这些内容的技术细节由基础架构来完成，但反映了上述信息是在模型层中被控制和使用的，因而在软件业务开发当中处于非常核心的地位。

      普遍使用的Java设计模式是尽可能地将模型定义为一些简单的Java Bean，然后将应用的业务逻辑放到用来操作这些模型的service层。在Play中，将这种传统的设计模式定义为反模式。

补充：

反模式：在开发、设计、管理中采用的糟糕的解决方案。

与优秀的改进型模式相反，反模式告诉我们应该尽量避免这些糟糕的模式而采用优秀的模式，以此起到警示作用。但反模式不是固定的，其中的“良好”或“糟糕”是对应于一定的环境而言的，因为一种良好的设计如果应用在错误的环境下也可能成为一种反模式。

      Martin fowler将上述的这种反模式命名为贫血模型（Anemic object model）：贫血域模型(Anemic Domain Model)最基本的表现是乍一看跟真实世界中的区别不大，有对象，有许多以名词命名的域空间。将这些对象与那些真实域模型进行对照，会发现两者在宏观的关系和结构方面有着紧密的联系。但美中不足的是当我们仔细观察其行为时，会意识到除了getXxx和setXxx方法以外很难发现有基于对象自身的操作。这些模型拥有约定俗成的设计规则：不要将业务逻辑放到域模型中，取而代之的是将这些逻辑交给上面的service层去处理，间接使用模型来对数据进行操作。

      这个反模式最大的恐怖之处在于，它与面向对象设计中的基本概念背道而驰，因为它没有将数据和操作放在一起。贫血域模型实际上仅仅是面向过程的设计风格，而且这种设计风格是面向对象的设计者们所反对的。可现在的情况是很多人认为贫血对象就是真实的对象，因此完全错过了去挖掘面向对象设计究竟是怎么一回事的机会。