浅谈领域逻辑和业务逻辑

在我们在对企业级应用进行架构设计时，分层的模型已经得到了广泛的应用(当然，基于总线的SOA 架构模式，看上去也是相当的美啊)。如果采用分层架构，不管在实现时采用什么样的技术路线，SSH 也好，Seam 也罢，在架构上一般都会分为以下层次，

表现层

业务层(应用层)

领域层

持久层

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

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

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

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

为了更好的理解领域模型的稳定性，可以这样看。通常我们的实体类都会做持久化(最常见的是保存到数据库中)。如果这个模型，即表达的领域概念是不稳定的，意味着我们要不断地去适应新的数据库结构(当然可以通过ORM 屏蔽掉数据库结构的影响)，这样系统没法做了。另外，我们要理解一个系统，最容易的办法也是先学习该系统处理的领域概念，而一般的系统培训首先都是讲解系统处理的对象。

业务层用来处理业务逻辑，即动态的逻辑。对于一般的MIS 系统和OLTP 系统来讲，最常见的就是业务流程和事务等。对应到软件模型里面来，就是控制类，用来协调表现层的边界类和领域层的实体类，共同完成用户的需求(用例)。这部分逻辑是经常会变化的，为了更好地适应这种变化，便产生了各种各样的设计模式。这也正是面向对象的优点所在-- 适应变化，易于扩展。

哈哈，讲点玄乎的。用中国的阴阳学说来讲，领域层就是阴，而业务层是阳，阴阳平衡才是王道。

如果清楚了业务层和领域层的概念，就能很好的理解所谓的失血，贫血，充血，胀血模型了。这四种模型中的血都是指领域层中包含的逻辑。

失血意味着领域层中没有业务逻辑，领域类只有getter 和setter

贫血意味着领域层中有着少量的、可能是跟持久化无关的逻辑

充血意味着所有的逻辑都在领域层，业务层只是充当门面Facade

胀血意味着没有业务层了

个人觉得，术语并不是最重要的，比如领域模型，在业界本来就有很多种不同的解释，孔乙己才会考证，"茴"字有三种写法，我们做系统的就没有必要去咬文嚼字了。还有方法论本身，如DDD,也并不是我们要重点考虑的。最重要的应该是其背后的思想和动机，也就是我们需要利用这个架构带来价值。分层架构的核心价值还是在于各层间是低耦合的，每一层的职责又是高内聚的(层内子系统的划分也要满足这个原则)。从而提高产品的可维护性和可扩展性。架构只要从整体上来看合理，满足了上面低耦合，高内聚的原则，管它什么血，都是好的架构。