关于应用服务设计的问题
我主要来自 n 层背景，并且我正在尝试更多地转向 DDD 架构。我正在尝试寻找设计应用程序服务的最佳实践，经过几次搜索后，我仍然有一些问题。当然，我知道我不是第一个问这些问题的人，所以如果你知道这些问题的答案在哪里，请给我指明方向，我会很乐意结束这个问题。
以下是我的主要问题：
您的签名应该有多“开放”？例如，是对签名更加严格并尽可能使用简单类型作为参数更好，还是使用以后可以在不破坏签名的情况下进行修改的对象（消息？）更好？
如果您想公开签名的变体，例如，根据各种（有时是可选的）搜索条件返回用户列表的 UserSearch 方法，是否最好：
A.使用重载
B.使用可选（或可为空）参数
C.将每个场景分解为自己独特的方法
D.使用消息
我知道其中一些答案是主观的，并且还取决于所有将调用您的应用程序服务的内容。但此时我只是想了解需要考虑的事项的总体方向以及其他最佳实践。
提前致谢。
I come from a mostly n-tier background, and I'm trying to move more towards a DDD architecture. I'm trying to find best practices for designing the application service, and after a few searches, am still left with a few questions. Granted, I know I can't be the first person to ask these questions, so if you know where these are answered, just point me the way and I'll happily close this.
Here are my main questions:
How "open" should your signatures be? For example, is it better to be more rigid with your signatures and use simple types as parameters when possible, or is it better to use objects (messages?) that can later be modified without breaking the signature?
If you want to expose variations of a signature, for example, a UserSearch method that returns a list of users based on various (and sometimes optional) search criteria, is it better to:
A. Use overloads
B. Use optional (or nullable) parameters
C. Break each scenario into its own unique method
D. Use messages
I know that some of these answers are subjective, and also depend on what all will be calling your application service. But I'm just trying to get a general direction of things to consider and other best practices at this point.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好问题。考虑 API 显然很重要。
1）对我来说开放程度取决于消费者是谁。如果此应用程序服务仅在您自己的解决方案和/或团队的上下文中使用，那么我认为拥有特定消息（或更确切地说是它们的接口）或 Dtos（数据传输对象）是可以的。不过，如果同样简单，那么在我看来，保持简单类型是最好的，如果被其他人使用的话，肯定会更好。如果它们还不够，那么接口消息仅提供足够的信息。同样，如果您要分发到不同的平台，那么简单类型的简单消息并不是一个坏方法。
2）为什么不使用 SearchCriteria 对象作为参数？如果您将其视为消息传递总线的起点，它可能是简单类型的 SearchCriteria 消息。
正如你所说，你的问题有点开放，但我有兴趣听到更多，因为听起来你至少在问正确的问题。
Good questions. Thinking about the API is obviously important.
1) How open would depend for me would depend on who the consumers are. If this application service is only being used within the context of your own solution and/or team then I think it's fine to have specific messages (or rather their interfaces) or Dtos (data transfer objects). Though if as easy then keeping to simple types is best in my book and definitely better if being consumed by others. If they don't suffice then interfaced messages that provide only just enough. Again if you are going to be distributed to different platforms then simple messages of simple types is not a bad way to go.
2) Why not have a SearchCriteria object as a paramater? It could be a SearchCriteria message of simple types if you are looking at this as a start of a messaging bus.
As you say, your question is a little open but I'd be interested to hear more as it sounds like you are asking the right questions at least.
杰拉德，正如您所指出的，这些问题一般来说很难回答。
我个人的偏好是尽可能在方法签名中使用原语。如果我需要将 3 个以上原语传递给方法，我会定义自定义数据传输对象。
想法是：如果多个值一起传递，它们很可能代表问题空间中的一个概念，因此应该成为一个对象。例如，如果您将 X 和 Y 坐标传递给方法，我建议创建一个表示该概念的 Point 类或结构。
我唯一一次最终会遇到签名的变化，那就是提供方便的方法，为方法参数提供默认值。继续上面的示例，Draw 方法可能不需要 Point，在这种情况下我将使用 (0,0)。
所以，我会用“不是很开放”来回答#1，用A回答#2。
我希望这会有所帮助。
Jerad, those are tough questions to answer generally, as you noted.
My personal preference is to use primitives in method signatures where possible. If I need to pass 3+ primitives to a method, I define custom data transfer objects.
The thinking being: if multiple values are being passed together, it's likely they represent a concept in your problem space, and thus should become an object. For example, if you are passing X and Y coordinates to a method, I'd recommend creating a Point class or struct that represents that concept.
The only time I'd end up with variations on a signature, it would be to provide convenience methods that provide default values for method parameters. To continue the above example, a Draw method might not require a Point, in which case I'd use (0,0).
So, I'd answer #1 with "not very open" and #2 with A.
I hope that helps.