领域逻辑用来表达业务概念,保证业务规则,存放业务数据和业务状态等。领域逻辑通常是通过领域模型中的对象来实现的,且这些对象并不知晓其持久化方式,不过数据仍旧被存储且行为也与相关的业务概念和规则保持一致。作为一个概念,强类型DataSet也可用来对领域进行建模。
虽然存储的技术细节将委托给基础设施完成,不过反映业务情况的状态将在这里控制并使用,领域逻辑这一层是业务软件的核心。
在有了软件需要实现的一系列操作之后,即可开始对应用逻辑进行建模。应用逻辑将组织业务对象和应用程序服务,以便满足表现层的需要。应用逻辑也叫应用层,这一层的职责对于保证业务非常重要,并负责与其他系统的应用层交互。这一层将保持简单,并不需要了解业务规则,只需要协调任务并将工作委托给下层中一系列协作的领域对象即可。
应用逻辑将包含处理问题的工作流,且实现于服务层中,与业务层分离开来。应用逻辑实现了用例,实现过程中使用到了领域逻辑所提供的功能。好的服务层应该是很简单的一层。
为什么在应用程序中需要有两种逻辑呢?这是因为应用逻辑很明显需要依赖于应用程序的用例和用户界面。若将这些逻辑放在领域模型中,那么领域模型中的类型自然不会有太好的重用性。也就是说,应用逻辑和领域逻辑的分隔是有代价的,主要为了处理复杂性。在一个程序中区分两种类型的逻辑并不是适用于所有情况的强制要求。
领域逻辑中的实体大多是独立的对象,对其他的实体没有太多的了解,实体中的交互(例如:创建、删除、或与其他实体执行工作)一般由服务层组织,并由领域逻辑管理。领域逻辑中实体可以直接交互的唯一情况将是实体之间存在逻辑上的上依赖,例如,Order于OrderDetail之间。