我主要来自 n 层背景，我正在尝试更多地转向 DDD 架构。我试图找到设计应用程序服务的最佳实践，经过几次搜索，仍然有一些问题。当然，我知道我不可能是第一个提出这些问题的人，所以如果你知道这些问题的答案，请给我指路，我会很高兴地结束这个问题。
这是我的主要问题：
您的签名应该有多“开放”？例如，最好对您的签名更加严格并尽可能使用简单类型作为参数，还是使用以后可以在不破坏签名的情况下修改的对象（消息？）更好？
如果您想公开签名的变体，例如，根据各种（有时是可选的）搜索条件返回用户列表的 UserSearch 方法，最好：
A.使用重载
B.使用可选（或可为空）参数
C.将每个场景分解成自己独特的方法
D.使用消息
我知道其中一些答案是主观的，并且还取决于所有将调用您的应用程序服务的内容。但我现在只是想大致了解要考虑的事情和其他最佳实践。
提前致谢。
【问题讨论】：
标签： asp.net-mvc architecture domain-driven-design
好问题。考虑 API 显然很重要。
1) 对我来说，开放程度取决于消费者是谁。如果此应用程序服务仅在您自己的解决方案和/或团队的上下文中使用，那么我认为拥有特定消息（或更确切地说是它们的接口）或 Dtos（数据传输对象）是可以的。尽管在我的书中保持简单类型是最好的，如果被其他人消费肯定会更好。如果它们还不够，那么接口的消息只提供足够的信息。同样，如果您要分发到不同的平台，那么简单类型的简单消息也不错。
2) 为什么不使用 SearchCriteria 对象作为参数？如果您将其视为消息总线的开始，它可能是简单类型的 SearchCriteria 消息。
正如您所说，您的问题有点开放，但我很想听听更多，因为听起来您至少提出了正确的问题。
【讨论】：
Jerad，正如您所说，这些问题通常很难回答。
我个人的偏好是尽可能在方法签名中使用原语。如果我需要将 3+ 个原语传递给一个方法，我会定义自定义数据传输对象。
想法是：如果多个值一起传递，它们很可能代表问题空间中的一个概念，因此应该成为一个对象。例如，如果您将 X 和 Y 坐标传递给方法，我建议创建一个表示该概念的 Point 类或结构。
唯一一次我最终会在签名上有所不同，那就是提供方便的方法，为方法参数提供默认值。继续上面的例子，Draw 方法可能不需要 Point，在这种情况下我会使用 (0,0)。
所以，我会用“不是很开放”回答 #1，用 A 回答 #2。
希望对你有帮助。
【讨论】：