领域模式概述
领域模型模式力求让对象模型能够与系统的概念模型匹配起来，这样的对象模型就叫做领域模型。领域模型描述了系统中涉及的实体，捕获了实体之间关系以及数据在其中的交换过程。
领域模型是项目中最为关键重要的部分，通过创建并共享领域模型，技术团队和业务团队能够彼此理解对方的想法及意图。领域模型此刻只是一个正式的模型，用来让技术团队和业务团队彼此理解并能良好交流。
从抽象的领域模型开始，我们即可开始向“一系列彼此相连的对象”努力。领域模型中的实体将成为一系列带有方法和属性的类，领域模型中的每个东西都需要用一个带有行为的类开表示，包含客户，发票项目和地址等。这样每个方法调用的顺序图都是一系列对象之间调用的组合。
领域模型可以看做是活动记录的“大哥”。领域模型完全与数据库独立，是一个尽可能贴近真实流程的模型，而不是去贴近架构师希望的流程。
架构师不过是个观察者，因此不应该对进行建模的流程好坏进行评价，软件架构师的工作是对流程进行建模。如果需要，会有另外的一些专家来帮助公司改进流程。
目前我们已经来到了领域模式的核心，即通常所说的领域驱动设计，这里有两点需要考虑。
首先，架构师和领域专家之间的紧密合作是保证企业流程的各个方面都能被所有人理解，且需求可以被正确完整地提取的关键。
其次，因为系统最终是基于软件和数据库的，所以在某个时候总会需要将抽象模型映射到对象模型和数据模型之上，这也是领域模型模式实现的困难所在，但也让它比其他模式更加强大。
注意：在设计领域模型时，数据库管理员（DBA）的正确角色应该是什么呢？数据库管理员应该充分理解建模后的业务流程，并创建出可以支持该领域模型的数据库。数据库管理员并不应该评价领域模型的好坏，就好像架构师不应该评价业务流程的好坏一样。不过领域模型很有可能无法带来一个简洁漂亮的存储层，但根据我们的经验，严格根据流程建模并适当提高数据库复杂性要比强制漂亮的数据库设计并使用随意的中间层好很多。
1，何时使用领域模型
领域模型模式使系统建模非常自由灵活，无需考虑平台和数据库的约束。抽象的领域模型表达了一些逻辑，并描述了一系列的流程，这就意味着执行同样的工作的两个应用程序的领域模型应该完全一致。这样看来，业务逻辑的重用性需要就成为判断是否值的使用领域模型的一个关键参数。
例如，若客户在需要网上银行系统的同时，也在考虑其他的应用程序—例如，后台界面，出纳支持或交易系统，那么可重用就会成为一个明显的优势。领域模型中的元素都可以容易地重用，包括账户，客户，支票，现金，存款，取款，贷款，股票等。
这样，设计领域模型的额外时间很快就会在重用过程中补偿回来，在一个经常要重用业务逻辑的长期项目中，成本很自然地被平摊了下来。
而若客户所需要的仅仅是一个基于现有后台的网上银行功能， 那么花费时间使用领域模型并不是一个很好的选择。这时仅需要对表现层进行一些架构设计，创建一个小型，自用的对象模型将表现层请求发送给现有后台即可。那么日期后的修改又该如何处理呢？仔细想想，你创建的只不过是个基于现有后台的Web站点，而最常见的复杂功能都是一些界面相关的需求。如果这样考虑，其实并不需要太过担心，也不会有什么需求会让设计无法支持。
复杂性是选择用领域模型模式的主要动力，复杂性应该按照现有需求来衡量，不过也应该考虑到日后可能出现的增强或修改需求。领域模型的初始代价较高，不过随着复杂性的增加，其代价是线性增加的。这样看来，在简单场景中使用领域模型虽然较为复杂，但是降低了由于后续添加修改需求所导致的复杂性暴增的风险。
2，领域模型的优势
在领域模型中，概念是用类来建模的，这种做法充分利用了面向对象设计的优势。你可以使用到面向对象中的所有特性，包括封装和继承，而同时又无需受到数据库结构的限制，这就意味着实体并不会察觉到丝毫有关底层使用的持久化机制。此外，日后你也可以替换数据库访问层，而不必担心这样做会影响到业务层。
之所以软件领域中面向对象设计在20年前开始广泛应用，很大程度上是因为业务逻辑越来越复杂，经常包括数以千计的规则和复杂纠结的流程。在这样的上下文中，对象的天生优势尽显无遗，架构师也可以轻地处理任何层次的复杂性。
3，领域模型的劣势
或许你在本章前面已经注意到，最大的优势往往也会成为最显著的劣势。领域模型也不能跳出这个圈套。首先，我们很难将整个系统构想成一个抽象的模型，其中用实体和关系来描述流程及机制。另一方面，你需要引入新的复杂性来处理现有的复杂性。
实现领域模型的一个主要障碍是对象和关系型数据库之间的不匹配。领域模型是一个面向对象的设计，和数据库或其它应用程序的约束完全无关，而仅受限于其建模的业务流程，这意味着同样的领域模型可以重用于其他需要同样逻辑的任意场景。模型是和业务相关的，且仅和业务相关。
不过这又怎么成为了系统的一个劣势呢？原因在于或早或晚，系统将要开始实现，数据需要持久化，因此你需要将模型映射至一个或多个数据库系统中。从应用程序角度来看，领域模型就是逻辑上的数据库，不过这个“数据库”仅仅是个对象模型，并没有提供关系接口。但创建这个关系型接口是必不可少的，且创建代价非常高。
若没有任何O/R映射工具，例如NHibernate或微软的Entity Framework，那么将很难实现领域模型模式。对象模型和关系模型之间的天生鸿沟为领域模型模式的应用带来了很大的困难。