创建一个只负责为其他服务发送电子邮件的服务是否有意义？
让我试着更清楚地表达我的怀疑并提出一些背景。顺便说一句，如果你愿意，你可以忽略术语“SOA”。我包含它的意图是传达我所说的是一个按功能划分的分布式系统。
我不确定“电子邮件服务”是否合适的原因是：
它提供了技术功能 而不是一个组织 功能。它没有组成 电子邮件，它只是处理 他们。有没有意义 电子邮件服务组成了 通过响应域来发送消息 事件？这会有益吗？ 有害？
似乎引入了依赖关系 进入所有其他服务 利用它。特别是，我不能 看看如何避免RPCish 客户与客户之间的互动 电子邮件服务。即使你使用 消息传递，消息将是 命令样式（告诉电子邮件 发送电子邮件的服务）就像我一样 明白这是不合适的 服务之间的通信 因为它们会增加耦合 客户必须具备的知识 关于它正在消费的服务 命令它告诉它该怎么做。 当然除非电子邮件服务 编写消息以响应 来自其他服务的域事件 （见第1点）。
多少是值得怀疑的 它提供的“服务”。其他 单词，不是SMTP服务器 “电子邮件服务”？当然， 自定义“电子邮件服务”可能提供 排队和解析等问题 送货报告。多少和什么 应该在电子邮件服务中 真的有必要吗？
另一种方法是让组织内的每项服务负责发送自己的电子邮件。但是，这意味着每个服务都必须依赖于SMTP服务器，但这与依赖于自定义“电子邮件服务”有什么不同？这也意味着每项服务都将负责排队和交付管理。这有益还是有害？
此外，电子邮件消息被视为域实体，这意味着除了发起消息的事件及其携带的信息之外，组织还对消息本身感兴趣。这意味着用户将有兴趣查看在上下文中发送的消息。例如，您可能会查看客户的帐户并要求查看发送给该客户的消息（这些消息可能包括：帐户创建的确认，下订单确认，订单发送通知，体验反馈请求等）。
如果我的问题做出某些假设或不清楚，我道歉，但根据我所写的内容，任何人都可以建议一种方法或讨论他们采取的方法以及如何解决问题？我已经四处寻找类似的问题并搜索了相关主题，但没有发现任何真正适用的内容，但如果有人能指出任何资源我会非常感激。我也会对那些指出我可能忽视或误解的事情的答案感兴趣。关于此事的任何形式的讨论对我来说都很有价值。
答案 0 :(得分：1)
这取决于具体情况。什么是服务？是技术资源还是业务资源？
如果您在技术层面工作，将大型技术解决方案划分为较小的部分（关注点分离等），那么我同意电子邮件服务可能适合这一点。
如果服务是商业服务（例如：“客户信用检查”），则电子邮件服务将不适用于此。
当然，你没有理由同时拥有两个：业务服务的“顶层”层，由（技术）解决方案（由各种子系统和层组成）实现其中包括技术服务的集合。