在领域驱动设计（Domain-Driven Design，简称DDD）中，聚合（Aggregate）是用来管理领域模型中对象的一致性和完整性的一种方法。聚合定义了一个确认的边界，该边界内的对象作为一个整体进行变更，保证了事务的一致性。而服务（Service）则是用来处理那些不属于任何特定对象的职责，或者是跨越多个对象的复杂业务逻辑。服务和聚合之间存在着一种协作关系，聚合通常用于处理领域内的状态变化，而服务则用于组织协调这些变化或者执行跨越多个聚合的操作。服务可以是领域服务（Domain Service）或应用服务（Application Service），分别负责领域逻辑和跨层协调。当一个行为或功能过于复杂，无法清晰地归入任何一个聚合，或者当一个行为涉及到多个聚合之间的交互时，倾向于将其抽取出来形成服务。将这些行为从聚合中抽取出来形成服务的主要考虑有以下几点：

1. 职责分离：当一个操作的实现细节开始模糊聚合的职责，则需要将其抽离。确保聚合专注处理与自身领域对象直接相关的事务。

2. 事务边界：当操作跨越多个聚合，涉及到基础设施的多个部分，如需要协调多个数据库或外部系统的事务时，通过服务来管理这些操作可以帮助明确定义事务的边界。

3. 技术或性能考虑：某些行为可能因为技术限制，比如处理大量数据或执行计算密集型任务，不适合在聚合内部实现。将其作为服务可以使用更适合的技术解决方案，如异步处理或分布式计算。

4. 复用性：如果某一功能在多个业务流程中均需要用到，将其设计成服务有利于提高代码的复用性。例如，一个用于计算定价的功能，如果在订单创建、促销活动和营销分析等多个场景中都会用到，那么可以将其设计成一个定价服务。

5. 解耦：通过将不相关的功能迁移到服务中，可以降低系统各部分之间的耦合度，使得系统更加模块化，更容易理解和维护。

例如，在一个电商系统中，如果有一个操作需要检查库存、更新订单状态并通知用户，这个操作跨越了库存管理聚合、订单管理聚合和用户通知聚合。在这种情况下，可以创建一个订单处理服务来协调这三个聚合的操作，保证事务的一致性，并且使每个聚合只需关注自己的核心责任。这种方式不仅提高了系统的可维护性和扩展性，也有助于清晰地表达业务需求。