比方说， 我们想建立一些像订票这样的系统（订票不是这里的关键，这只是一个例子）
所以我们有一个 User 类，Ticket 类等
我们还有一个 TicketService 类，它提供了 bookTicket() cancelTicket() 等方法
类图中，TicketService 应该包含还是不包含？
如果没有，bookTicket() 或 cancelTicket() 应该显示在类图上的什么位置， 在票证类或用户类中（因为用户创建票证）
这取决于你想代表什么。如果您希望在类图中忠实地表示您的代码，那么是；如果您只是想解释业务域的逻辑（即域中的业务实体）并且您不希望混乱，那么不您可以删除服务类。这是基于主观/意见的，取决于您需要做什么。
如果你想避免使用服务类，但又想用行为来表示域的逻辑，那么你可以简单地在 Ticket 类中添加“book()”和“cancel()”操作。这将是面向对象的标准方法——即将行为（和数据）封装在负责它的对象内。
如果您要尽可能接近实现地对软件进行建模（通常在建模过程的后期阶段），则应该这样做。
在早期阶段（分析模型），您应该专注于对领域类及其关系进行建模，并且仅使用类的基本属性和方法（即，它们的职责是什么，系统的“什么”，这可以包括边界类、控制器和模型实体的本质）。在后期阶段（项目模型），您应该关注how，即进一步详细说明域类如何真正实现和执行，这可能涉及将一个类拆分为两个或多个其他类。 当然，所有这些“阶段”谈话都不是硬科学，也不是强制性的。通常两个阶段都会被破坏在一起，或者后一个阶段的痕迹会出现在早期阶段。