电子邮件服务是否是适当的“服务”？在 SOA 中？
创建一个唯一职责是为其他服务发送电子邮件的服务是否有意义？
让我尝试更清楚地表达我的疑问并提供一些背景信息。顺便说一句，如果您愿意，可以忽略术语“SOA”。我加入它的目的是为了传达这样的信息：我正在谈论一个按功能分区的分布式系统。
我不确定“电子邮件服务”是否合适的原因是：
它提供了技术功能 而不是一个组织 功能。它不构成 电子邮件，它只是处理 他们。这样做有意义吗？ 电子邮件服务撰写 通过响应域来发送消息 事件？这是否有益或 有害吗？
好像引入了依赖 进入所有其他服务 利用它。特别是我不能 看看如何避免 RPCish 客户与客户之间的互动 电子邮件服务。即使你使用 消息传递，消息将是 命令风格（告诉电子邮件 发送电子邮件的服务）作为我 了解它不适合 服务之间的通信 因为它们增加了耦合 客户必须具备的知识 关于它所消耗的服务 命令它告诉它做什么。 当然除非电子邮件服务 撰写消息以响应 来自其他服务的域事件 （见第1点）。
有多少是值得怀疑的 它提供的“服务”。在其他方面 话说，SMTP服务器不是已经有了吗 “电子邮件服务”？当然， 自定义“电子邮件服务”可能提供 诸如排队和解析之类的事情 交货报告。多少和什么 应该在电子邮件服务中 真的有必要吗？
另一种方法是让组织内的每个服务负责发送自己的电子邮件。但是，这意味着每个服务都必须依赖于 SMTP 服务器，但这与依赖于自定义“电子邮件服务”有什么不同吗？这也意味着每个服务都将负责排队和交付管理。这是有益还是有害？
此外，电子邮件消息被视为域实体，这意味着除了发起消息的事件及其携带的信息之外，组织还对消息本身感兴趣。这意味着用户将有兴趣查看在上下文中发送的消息。例如，您可能会查看客户的帐户并要求查看发送给该客户的消息（这些消息可能包括：帐户创建确认、订单下达确认、订单发货通知、体验反馈请求等）。
如果我的问题做出某些假设或不清楚，我深表歉意，但根据我所写的内容，任何人都可以提出一种方法或讨论他们所采取的方法及其效果如何？我已经四处寻找类似的问题，并用谷歌搜索了该主题，但没有找到任何真正适用的内容，但如果有人能指出任何资源，我将不胜感激。我也对指出我可能忽略或误解的事情的答案感兴趣。对这个问题的任何形式的讨论对我来说都是有价值的。
Does it make sense to create a service whose only responsibility is to send emails for other services?
Let me try to express my doubts more clearly and give a little bit of context. BTW, you can ignore the term "SOA" if you like. My intent in including it was to communicate that I am talking about a distributed system that is partitioned by function.
The reasons why I am uncertain as to whether an "Email Service" is appropriate or not are:
It provides a technical function
rather than an organization
function. It doesn't compose the
email messages, it just processes
them. Would it make sense to have
the Email Service compose the
messages by responding to domain
events? Would this be beneficial or
harmful?It seems to introduce dependencies
into all other services which
utilize it. Particularly, I can't
see how one could avoid RPCish
interactions between the client and
the Email Service. Even if you use
messaging, the messages would be of
the command style (telling the Email
Service to send an email) which as I
understand it are inappropriate for
communications between services
since they increase coupling due to
the knowledge the client has to have
about the service it is consuming in
order for it to tell it what to do.
Unless of course the Email Service
composes the messages in response to
domain events from other services
(see point 1).It is questionable how much
"service" it provides. In other
words, isn't the SMTP server already
the "Email Service"? Of course, the
custom "Email Service" might provide
things like queuing and parsing of
delivery reports. How much and what
should be in the Email Service for
it to really be necessary?
The alternative would be to have each service within the organization be responsible for sending out it's own email messages. However, this would mean that each service would have to be dependent on the SMTP server, but is that any different from being dependent on a custom "Email Service"? It would also mean that each service would be responsible for queuing and delivery management. Is this beneficial or harmful?
In addition, the email messages are considered domain entities, meaning that the organization is interested in the messages themselves in addition to the events that initiated them and the information that they carried. This means that users will be interested in viewing the messages that were sent out within context. For example you might look at a customer's account and ask to view the messages that were sent to that customer (these messages might include: account created confirmation, order placed confirmation, order shipped notification, experience feedback request, etc.).
I apologize if my question makes certain assumptions or is unclear, but based on what I've written, can anyone suggest an approach or discuss an approach that they have taken and how it worked out? I've already looked around SO for similar questions and googled on the topic but did not find anything that really applied, but if anyone can point out any resources I would greatly appreciate it. I would also be interested in answers that point out things that I might be overlooking or misunderstanding. Any sort of discussion on the matter seems valuable to me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于上下文。什么是服务？它是技术资源还是业务资源？
如果您在技术层面工作，将大型技术解决方案划分为较小的部分（关注点分离等），那么我同意电子邮件服务可能很适合于此。
如果服务是商业服务（例如：“客户信用检查”），则电子邮件服务不适合于此。
当然，您没有理由同时拥有两者：业务服务的“顶层”，由（技术）解决方案（由各种子系统和层组成）实现，其中包括技术服务的集合。
It depends on the context. What is a service? Is it a technical resource or a business resource?
If you were working at a technical level, partitioning a large technical soluiton into smaller parts (separation of concerns, etc) then I'd agree that an email service might well fit into this.
If the services are business services (e.g: "customer credit check") then an email service wouldn't fit into this.
And of course there's no reason why you can have both: a "top" layer of business services, implemented by a (technical) solution (that is composed of various sub-systems and layers) which includes a collection of technical services.