为什么80%的码农都做不了架构师？>>> 
一、为什么要使用领域模型
1.有助于团队创建一个业务部门与IT部门都能理解的通用模型，并用该模型来沟通业务需求、数据实体、过程模型。
2.模型是模块化、可扩展、易于维护的，同时设计还反映了业务模型。
3.提高了业务领域对象的可重用性和可测性。
二、领域的分层架构
在Eric Evans《领域驱动设计--软件核心复杂性应对之道》中对领域的分层架构如下：
1.用户界面（表现层）：负责给用户展示信息，并解释用户命令。
2.应用层：该层协调应用程序的活动。不包括任何业务逻辑，不保存业务对象的状态，但能保存应用程序任务过程的状态。
3.领域层：这一层包括业务领域的信息。业务对象的状态在这里保存。业务对象的持久化和它们的状态可能会委托给基础设施层。
4.基础设施层：对其它层来说，这一层是一个支持性的库。它提供层之间的信息传递，实现业务对象的持久化，包含对用户界面层的支持性库等。
三、如何创建领域模型
1.寻找概念类。
2.将其绘制为UML类图中的类。
3.添加关联和属性。
四、领域模型的开发步骤
1.对领域进行建模。
2.设计。
3.开发。
4.单元测试和集成测试。
5.基于设计和开发来完善、重构领域模型。
6.使用更新的领域模型重复上述步骤 。
五、实际项目设计
1、层次结构：
2、层次之间的交互
A、页面提交表单数据到Action，Action创建DTO对象并设置相应属性值为表单数据。
B、Action传递DTO对象给Facade。
C、Facade中套用ServiceTemplate事务模板以加入事务管理，在ServiceTemplate中根据具体业务调用Factory或Reposistory，分别create或者load出DomainModel对象。
D、Facade传递DomainModel对象给Service。
E、Service执行具体业务逻辑（调用DomainModel对象相应的业务方法）。
F、Service调用Reposistory对状态已改变的DomainModel对象进行持久化操作（调用相应DAO）。
注： 在Facade或Service中如果需要查询DomainModel对象中的属性值，调用DomainModel对象的getDataInfo()方法得到DataInfo对象，通过DataInfo对象查询所需数据，包括Service返回给Facade业务处理结果中所包含的业务数据。
3、对于DomainModel的设计
DomainModel基于贫血模型来设计。在Robbin《总结一下最近关于domain object以及相关的讨论》一文对于贫血模型领域的切分原则写到： 引用 Rod Johnson提出原则是“case by case”，可重用度高的，和domain object状态密切关联的放在Item中，可重用度低的，和domain object状态没有密切关联的放在ItemManager中。 我提出的原则是：看业务方法是否显式的依赖持久化。 在该项目中DomainModel内的业务逻辑方法没有任何对DAO接口的依赖，如果需要对DomainModel进行持久化操作全部由Service调用Reposistory的store()方法进行处理，对DomainModel的持久化操作已全部封装于Reposistory中。DomainModel只提供改变自身状态的业务处理方法。
4、对DomainModel的访问原则
A、必须从领域模型的根部操作模型的各个属性 例如一个领域模型结构如下：
Java代码
1. public class PersonDomainModel {
2. Person person;
3. Bank bank;
4. 5. public void modifyPerson(String name, String age) {
6. this.person.setName(name);
7. this.person.setAge(age);
8. }
9. }
操作该领域模型的person属性只能通过modifyPerson()方法进行，而不能直接调用person对象的setter方法。
B、必须保持领域模型的完整性。最初由Factory构造一个模型的时候，就必须将其进行完整的初始化，而不是只构造一部分，然后在接下来的处理过程中逐步完善。
5、Factory和Reposistory的职责
Factory只负责领域模型对象的创建（从无到有）； Reposistory对持久化进行了封装，它操作的是已存在的领域模型对象（从数据库中读取数据or重新持久化到数据库）
6、项目待优化部分
在Service调用Reposistory的store()方法进行持久化操作时，如果某个业务仅对DomainModel的一部分属性进行了修改，在持久化到数据库中时仍然会将DomainModel的所有属性全部进行一次update操作。这样的数据库操作没有必要，只需对DomianModel中修改过的属性进行持久化操作即可。可以考虑在DomainModel上提供一个类似保存所有修改属性的列表，在Reposistory持久化时仅对该列表中的修改属性进行操