在软件设计中，并非所有的对象都需要通过标识或属性进行区分。领域驱动设计中，使用服务（Service)来定义具有活动或动作的对象。事实上也确实如此，并非所有的对象都适合使用实体或值对象来进行建模。服务强调与其他对象的操作，是通过定义能够为使用者做什么来实现的。也就是说，服务倾向于动词领域，而非名词领域。
5.1 服务对象的基本特征
按照领域驱动设计的说法，一个好的服务应该具有以下特征：
1）与领域概念相关的操作，不是Entity或ValueObject的一个自然组成部分。
2）接口是根据领域模型的其他元素定义。
3）操作是无状态的。操作的无状态是指任何调用者都能使用，而无需关注实例的历史状态。
5.2 服务与领域层
在领域涉及中，服务无处不在，大体上包括以下几种不同层次。
1、应用层：定义与应用相关的基础服务，例如在处理资金转账业务时，定义一系列服务，1、包括获取输入，2、发送消息给领域层服务，由其完成动作的执行；3、监听确认消息等。
2、领域层：处理与相关的服务，例如，处理有上述转账业务发起的请求，例如进行结果的确认等。
3、基础设施层：发送消息通知。
5.3 服务的粒度
在概念建模中，通过控制领域层中接口的力度，可以有效的实现客户端与实体和值对象的耦合。通过合理的模式确保接口的简单性，将便于在大型或分布式系统中对组件进行打包的粒度控制，这实际上也是微服务架构中，服务粒度细分的理论基础。
6 包或模块
模块，是软件工程学中自古有之的基本概念。在软件系统设计中，经常会按照各种各样的类别进行分解，有时候按照技术架构来分割，有时候则按照开发者的任务例如按照用例来进行细分，有的在软件重构过程中，甚至会沿用历史架构早期形成的模块划分。
在软件工程学中，高内聚，低耦合是基本的概念，而在模块之间的关系，成为耦合，而模块内部的关系，成为内聚。因此，好的软件项目，模块之间应该低耦合，而模块内部则应该高内聚。但是模块的划分，跟软件分层划分一样，不应该仅仅只是代码层面的划分，而应该是概念模型角度的划分。不连贯的思想或者“一锅粥”式的模块划分，最终只会造成系统开发的严重不可控。
领域驱动设计认为，模块，是一种非常重要的表达机制。模块的选择应该取决于被花费到模块中的对象的意义。当某些对象在模块中被创建时，实际上相当于告诉下一位开发者，这些对象间是通过模块来实现了某种关系。
选择能够描述系统的模块，并使之饱含一个内聚的概念集合。应该基于模块来实现概念组合的方式，从而可以向相互独立地理解和分析这些概念。对模型进行精化，直到可以更具高层领域概念对模型进行划分，同时，相应的代码也不会产生耦合。
7 结论
随着系统设计规模和复杂度的增加，模块化变得更加重要。领域模型中的每个概念都需要在实现元素中反映出来。实体、值对象、他们之间的关联关系、领域服务以及用于组织元素的模块都是实现领域模型相对应的地方。实现中的对象、指针和检索机制必须直接、清楚地映射到模型对象。