根据Eric Evans在《Domain-Driven Design》中的说法，所谓Domain，简单地说就是指问题域；Domain Model就是和Domain中特定问题相关的模型。
html
为何要Domain Model？由于它相对于原来的Transaction Script方式（即传统的那套Entity+DAO+Service方式），可以比较好地处理复杂的业务逻辑。如下是摘自《Patterns of Enterprise Application Architecture》的一段原话：The value of a Domain Model lies in the fact that once you've got used to things, there are many techniques that allow you to handle more and more complex logic in a well organized way. As we get more and more algorithms for calculating revenue recognition, we can add these by adding new recognition strategy objects. With the Transaction Script we are adding more conditions to the conditional logic of the script. 数据库
Domain Model的各类角色：框架
领域模型主要由如下角色组成的：post
Entity：具备惟一标识的对象，且该标识和该对象的属性值分离；
单元测试
Value Object：主要是一些属性值定义的对象，好比说Address等；测试
Factory：负责Entity和Value Objec的建立（不是特别复杂的状况下不常见）； 设计
Repository：封装持久层框架，管理Entity的集合，定义查找和删除等方法；htm
Service：它实现整个业务逻辑的工做流，通常负责一些没法指派给单个Entity的行为。对象
按Eric Evans的说法，Domain Model还应该包含Association和Aggregation，但这些更多地体现着Entity和Value Object之间的关系，虽然属于设计时应该仔细考虑的方面，但我的以为把他们放进来有点牵强。blog
开发Domain Model：
结合《Pojos in Action》和《Domain-Driven Design》的观点，我我的认为比较行之有效的一套方法是：
先识别一个用户用例，好比下单动做等；
而后从中去识别出Entity和Value Object（这一步应该比较容易）；
接着去考察它们之间的关联关系（好比如何在各个Entity间提供导航等）和聚合关系（肯定Entity和Value Object的操做边界，好比是否提供级联删除等）；
识别出Service方法，尽可能把能分发给单个Entity或者Value Object的方法分发出去（尽可能少担忧这样会使Entity过于“肥胖”，事实上，若是它们的确过于“肥胖”，再进行重构也不为迟）。这一步经过TDD的方式来Mock对象会对开发带来极大的便利，由于这样能够进来减小对象间依赖，历来能够很轻易地作到自顶向下的开发。
最后一步，完成各个对象的功能，并使他们功过单元测试（Repository须要进行集成测试）。
一些值得注意的问题：
首先是关于Domain Model粒度的问题。通常来讲，粒度越细容易增长整个对象模型的复杂性，但却能够提供更好的重用性。我我的比较倾向于相对细些的模型，由于系统的复杂度通常都是由业务逻辑的复杂性，而不是对象模型的复杂性形成的，因此代码的重用应该成为咱们的第一考虑。另外，目前日臻完美的持久层框架也为咱们映射细粒度的Domain Model提供了一个比较好的条件。
关于Entity调用Repository方法的问题。 这个问题有些争论，有人认为它们不该该知道有Repository，但我以为在处理一些不会引发歧义的逻辑时，在Entity来调用Repository方法也何尝不是一种很好的解决办法，但这种方式也不宜用的过多。另外一个问题是在Entity中如何调用Repository：Entity通常由持久层框架建立，因此在Entity中添加一个指向Repository的方法显然是不合适的。比较好的解决方法是把Repository做为一个参数传到Entity要使用它的方法中去。
业务逻辑的组织问题。对复杂易变的业务逻辑，最好用Strategy方式抽象出一个Policy类进行单独地存放。这样作有几个好处：第一，使逻辑一目了然；第二，能够比较方便地和业务人员讨论如何对这些逻辑进行处理；第三，可以比较灵活地应对业务逻辑的变化。好比在咱们的项目中，对于不一样商品和不一样用户的订价策略就至关复杂，并且前先后后也通过几回变化。若是不进行单独的抽象，修改这些代码将是件很恐怖的事情。
另外关于关联和聚合边界在设计的时候也须要特别注意，不然极其容易引发很是复杂的数据库事务。关于这个问题将在事务管理中进行阐述。
大概先写这些吧。之后想到了或者遇到了什么其余的问题再来补好了～～