服务类和助手类之间的区别

我想知道什么将Service类与Utility类或Helper类区分开来？仅具有基础方法的类称为dao是服务吗？使用Helper类是否违反SRP？

线条可能有点模糊，但是我这样看：

• 服务类/接口提供了一种客户端与应用程序中的某些功能进行交互的方式。这通常是公开的，具有一定的商业意义。例如，一个TicketingService接口可以让你buyTicket，sellTicket等等。

• 助手类倾向于对客户端隐藏，并且在内部用于提供一些没有业务领域意义的样板工作。例如，假设您要将日期转换为时间戳，以便将其保存到特定的数据存储中。您可能有一个使用执行该处理DateConvertor的convertDateToTimestamp方法的实用程序类。

服务不仅与DAO紧密耦合，而且是一个比持久性更广泛的术语/使用模式

如果按照该原理进行编码，则助手类不会违反SRP。也就是说，每个方法都应该做一件事情，一件事情要做，该类应该执行一种类型的实用程序帮助（例如，日期转换），并做到这一点。

这不是一个科学的定义，但我通常会认为服务类在应用程序中具有一定的上下文，而助手则更为通用，并且不在乎他们在帮助什么应用程序。

对我来说，我遵循Eric Evans的定义，service它是这样的：

通常，在设计良好的系统中，大多数类（在域模型中）具有很明确的职责或功能，因为它们处理模型中的特定实体或一组实体。

即

• 帐户，帐户工厂，帐户存储库等
• 客户，客户工厂，客户存储库等

当您具有不属于任何特定实体的功能时，可能很难找到适合其放置的位置。即某种东西封装了一个涉及AccountAND的过程Customer。

因此，这就是a service出现的地方。在这里，您将代码放入域模型中，但并不自然地属于一个实体/组件或另一个实体/组件。

我认为helper这是一种策略课程。对我来说，这是放置代码的地方，该代码需要由各种类重用，但可能不适合使用它的类层次结构中的抽象方法。我个人觉得这个词helper有点含糊，在我的模型中并没有真正使用它们。尽管它们存在于我使用的库中。

服务类别：包含业务逻辑。
助手类：此类是可重用组件的一种类型。

您混合了两个不相关的主体。服务和帮助程序类未连接。特别是术语“服务类”具有误导性-我认为您所指的是“服务”，其抽象程度高于类。服务的特点是

“一种允许访问一个或多个功能的机制，其中访问是使用规定的接口提供的，并且与服务描述所指定的约束和策略一致地进行行使。”

该定义会根据您的上下文而稍有变化。但是，关键是术语“服务”处于抽象级别，架构级别和领域知识级别。“帮助程序类”是一种设计模式（尽管它是一种反模式，因为它们倾向于演变为Blob或God类），它指的是封装通用操作的类（请注意，该类处于较低的抽象级别并且已连接）该应用程序/解决方案的知识）。我知道以下事实：几乎不存在不包含任何帮助程序类的软件，但这仍然是一种不好的做法。

需要警惕的是DDD中“服务”的多种定义：

应用程序服务：它们位于应用程序层中，并与域和数据层进行通信，它们是外部系统/ UI与DDD系统进行交互的接口。

域服务：域服务或应用程序层可以使用它，并且包含的​​业务逻辑不能很好地适合一个特定实体。

基础结构服务：域使用这些服务与外部资源进行通信。

Helper类倾向于包含可被多个实体重用的代码或算法，因此在不违反DRY原理的情况下，不能真正进入实体。它们可能最接近域服务，因为它们可以实现相同的目的（将实体的业务逻辑外部化），但是出于不同的原因而这样做。