关于应用服务设计的问题

Question

我来自一个大多数是n层的背景，我正试图更多地转向DDD架构。我正在尝试找到设计应用程序服务的最佳实践，经过几次搜索后，我仍然会留下一些问题。当然，我知道我不能成为第一个提出这些问题的人，所以如果你知道这些问题的答案，请指出方向，我会高兴地关闭它。

以下是我的主要问题：

1. 你的签名应该如何“开放”？例如，最好是使用签名更加严格，并在可能的情况下使用简单类型作为参数，还是更好地使用以后可以修改而不破坏签名的对象（消息？）？

2. 如果您想公开签名的变体，例如，基于各种（有时是可选的）搜索条件返回用户列表的UserSearch方法，最好是：

   一个。使用重载

   B中。使用可选（或可为空）参数

   ℃。将每个场景分解为自己独特的方法

   d。使用消息

我知道其中一些答案是主观的，并且还取决于所有人将会调用您的应用程序服务。但是，我只是想在此时考虑事项的总体方向和其他最佳实践。

提前致谢。

Answer 1

杰拉德，正如你所指出的那样，这些问题一般都是难以回答的问题。

我个人的偏好是尽可能在方法签名中使用原语。如果我需要将3个以上的基元传递给方法，我定义自定义数据传输对象。

思维是：如果多个值一起传递，它们很可能代表您的问题空间中的一个概念，因此应该成为一个对象。例如，如果要将X和Y坐标传递给方法，我建议创建一个表示该概念的Point类或结构。

我唯一一次在签名上有变化，就是提供便捷方法，为方法参数提供默认值。要继续上面的例子，Draw方法可能不需要Point，在这种情况下我会使用（0,0）。

所以，我会用“不太开放”回答＃1，用A回答＃2。

我希望有所帮助。

Answer 2

好问题。考虑API显然很重要。

1）开放对我来说有多大取决于消费者是谁。如果此应用程序服务仅在您自己的解决方案和/或团队的上下文中使用，那么我认为拥有特定消息（或者更确切地说是它们的接口）或Dtos（数据传输对象）是完美的。虽然如果简单，那么保持简单类型在我的书中是最好的，如果被其他人消费肯定会更好。如果它们不够，那么只提供足够的接口消息就足够了。再次，如果您要分发到不同的平台，那么简单类型的简单消息并不是一个糟糕的方式。

2）为什么不将SearchCriteria对象作为参数？如果您将此视为消息传递总线的开头，它可能是简单类型的SearchCriteria消息。

正如你所说，你的问题有点开放，但我有兴趣听到更多，因为听起来你至少在问正确的问题。