我知道这是一个自以为是的问题。然而，它常常出现在工作中。 在创建方法时，通常很难知道哪个类应该负责。
e.g。
bool result = ProductService.CategoryHasSoldOutOfProducts(int categoryId)
VS
bool result = CategoryService.CategoryHasSoldOutOfProducts(int categoryId)
在我看来， CategoryService 应该负责，因为该方法采用 categoryId 并且特定于类别。
我工作的其他人说 ProductService 应该负责，因为该方法正在处理产品已售罄。
只是想更好地理解服务架构和良好的流程。我对其他人的解释感兴趣，为什么他们会选择一个而不是另一个。
由于
答案 0 :(得分：1)
免责声明 - 这是纯粹的恕我直言。我本着设计头脑风暴的精神回答这个问题。
基于OP，似乎Category和Product之间的关系是可选的一对多：Category（0..1）＆lt; --------＆gt; （*）产品。
实施明智，这意味着Category实体可能具有Container of Products，而Product实体具有对可能为NULL的Category的引用。
在这种情况下，我同意将CategoryHasSoldOutOfProducts置于Category实体的责任下的决定。方法名称明确暗示类别实体应负责通知其API用户其产品的状态。
还有另一种选择：association class/entity。这个实体背后的动机是描述两个其他实体之间的关系。
在这种情况下，您可以拥有一个功能关联实体，我们将为此示例调用ProductContainment。
ProductContainment将没有内部状态，并将保存随Category和/或Product实体提供的功能作为参数。 然后，协会实体有责任提供与类别和产品如何相互关联相关的功能的实现。
如果你最终使用ProductContainment - 那么CategoryHasSoldOutOfProducts应该是它的一个功能。
答案 1 :(得分：1)
既然你在征求意见，那么这是我的意见： （免责声明：这可能是你在商业世界中无法轻易实现的东西）
当你使用术语“类”时，我假设你想要面向对象的东西。问题是，服务不是可以创建的有效对象。相反，它只是函数的命名空间。
此外，它非常一般。这就像叫一个班级“经理”。你可以将所有东西放在其中，这个类有可能增长到拥有数百个函数。
我的建议：创建小实体。只需调用构造函数，即可在不使用任何setter的情况下创建。如果您发现对象需要更多功能，请创建一个更聪明的装饰器并为您完成工作。
我需要更多关于您的环境的更多详细信息，但我想在您的情况下，您将拥有包含产品的类别类，并知道它何时售罄。想象一下，你有一个团队，每个人都知道一些事情。让合适的人做这些事情，远离管理者或服务。