浅谈领域逻辑和业务逻辑

现在我们在对企业级应用进行架构设计时，分层的模型已经得到了广泛的应用。不管在实现时采用什么样的技术路线，SSH 也好，Seam 也罢，在架构上一般都会分为以下层次，

表现层

业务层(应用层)

领域层

持久层

 

可能有些初学者对这个架构感觉还是很抽象，难以理解。以下我结合自己的实践，谈谈我的一点理解，希望能起到抛砖引玉的作用。

表现层和持久层，都是比较容易理解的，因为这两个层所承担的职责非常的明确并且没有什么争议。表现层就是负责展现和用户交互的，而持久层主要负责数据的持久化。

业务层和领域层可能就没那么容易理解了，并且还有一些争议(焦点在于是否应该让实体类包含大量的业务逻辑)。下面我来讲讲我的理解。

简单的讲，领域层是用来描述领域概念的。领域逻辑可以理解为领域中相关概念以及这些概念间静态的，稳定的，不太会变化的关系。不管我们做什么系统， 都是为某个领域服务的。比如CRM,就是服务客户关系领域的。在这个领域里面，自然会有客户，商机，产品，订单,市场活动,价格表等概念。这些概念本身是 稳定的，并且其中的关系也是稳定的。对应到我们的软件模型里面来，就会体现为实体类和实体类之间的静态关系，如关联，组合，聚合，继承等（在领域层，不太 会有依赖关系的）。

为了更好的理解领域模型的稳定性，可以这样看。通常我们的实体类都会做持久化(最常见的是保存到数据库中)。如果这个模型，即表达的领域概念是不稳 定的，意味着我们要不断地去适应新的数据库结构(当然可以通过ORM 屏蔽掉数据库结构的影响)，这