领域逻辑与应用逻辑的区分，是服务层存在的理由

企业应用常常要给不同种类的客户提供接口（数据加载器、用户界面、系统集成入口等），这些接口目的各异，却往往共享一套相似的交互逻辑——存取处理数据、调用业务逻辑，如果任由每个接口各自实现这套逻辑，会造成大量冗余代码。服务层的解法是把业务逻辑拆成两类分别对待：”领域逻辑”只关心问题领域本身（比如计算合同收入确认的具体策略），”应用逻辑”则关心应用的职责——围绕这个领域逻辑结果需要做的后续协调（比如通知合同管理者、触发系统集成），有时也被称为”工作流逻辑”。为什么要把这两类逻辑分开放进两个层？如果把应用逻辑也塞进纯粹的领域对象类里会带来两个具体坏处：一是一旦领域类里掺了针对具体应用的逻辑（或者依赖某个特定应用的软件包），这个类在其他应用之间的可复用性就会打折扣；二是将来如果要把这部分应用逻辑迁移到工作流引擎之类的专门工具里重新实现，两种逻辑纠缠在同一个类里会让这件事变得更困难。服务层因此把每种业务逻辑各自独立成一层：领域逻辑继续留在纯粹的领域对象类里保持可复用，应用逻辑集中到服务层，由服务层的操作负责协调具体用例所需的响应——这不只是”分层带来常规好处”的老生常谈，而是为了保护领域对象类在不同应用之间的可复用性这个具体目标。