Является ли служба электронной почты подходящей «службой» в SOA? - PullRequest
2 голосов
/ 17 ноября 2010

Имеет ли смысл создавать службу, единственной обязанностью которой является отправка электронных писем для других служб?

Позвольте мне попытаться выразить свои сомнения более четко и дать немного контекста.Кстати, вы можете игнорировать термин «SOA», если хотите.Моим намерением, в том числе, было сообщить, что я говорю о распределенной системе, которая разделена по функциям.

Причины, по которым я не уверен, является ли «Служба электронной почты» подходящей или нет:

  1. Она обеспечивает техническую функцию, а не организационную функцию.Он не составляет сообщения электронной почты, он просто обрабатывает их.Имеет ли смысл, чтобы служба электронной почты составляла сообщения, отвечая на события домена?Будет ли это полезным или вредным?

  2. Кажется, что вводит зависимости во все другие службы, которые его используют.В частности, я не понимаю, как можно избежать взаимодействия RPCish между клиентом и службой электронной почты.Даже если вы используете обмен сообщениями, сообщения будут иметь командный стиль (сообщающий службе электронной почты об отправке электронной почты), что, как я понимаю, неприемлемо для обмена данными между службами, поскольку они увеличивают связь благодаря знаниям, которые клиент должен иметь ообслуживание, которое он потребляет, чтобы сказать ему, что делать.Если, конечно, Служба электронной почты не создает сообщения в ответ на события домена от других служб (см. Пункт 1).

  3. Сомнительно, сколько «услуг» она предоставляет.Другими словами, не является ли SMTP-сервер уже «службой электронной почты»?Конечно, пользовательский «Сервис электронной почты» может обеспечивать такие вещи, как организация очередей и анализ отчетов о доставке.Сколько и что должно быть в службе электронной почты, чтобы она действительно была необходима?

Альтернативой может быть назначение каждой службы в организации отвечать за отправку своих собственных сообщений электронной почты.Однако это будет означать, что каждая служба должна зависеть от SMTP-сервера, но отличается ли она от зависимости от настраиваемой «службы электронной почты»?Это также означает, что каждая служба будет отвечать за организацию очередей и управление доставкой.Это полезно или вредно?

Кроме того, сообщения электронной почты считаются объектами домена, что означает, что организация заинтересована в самих сообщениях в дополнение к событиям, которые их инициировали, и информации, которую они передали.Это означает, что пользователи будут заинтересованы в просмотре сообщений, которые были отправлены в контексте.Например, вы можете просмотреть учетную запись клиента и попросить просмотреть сообщения, которые были отправлены этому клиенту (эти сообщения могут включать: подтверждение создания учетной записи, подтверждение размещения заказа, уведомление о доставке заказа, запрос обратной связи и т. Д.).

Я прошу прощения, если мой вопрос делает определенные предположения или неясен, но на основании того, что я написал, может ли кто-нибудь предложить подход или обсудить подход, который они выбрали, и как это сработало?Я уже искал вокруг SO подобные вопросы и гуглил по теме, но не нашел ничего, что действительно применимо, но если кто-то сможет указать какие-либо ресурсы, я был бы очень признателен.Мне также были бы интересны ответы, которые указывают на вещи, которые я мог бы упускать из виду или неправильно.Любая дискуссия по этому вопросу кажется мне ценной.

1 Ответ

1 голос
/ 17 ноября 2010

Это зависит от контекста.Что такое сервис?Это технический ресурс или бизнес ресурс?

Если вы работали на техническом уровне, разделите большое техническое решение на более мелкие части (разделение проблем,и т. д.), тогда я согласился бы, что служба электронной почты вполне могла бы вписаться в это.

Если эти услуги являются бизнес-услугами (например, «проверка кредитоспособности клиента»), тогда служба электронной почты не подойдет для этого.1009 *

И, конечно, нет причин, по которым вы можете иметь оба: «верхний» уровень бизнес сервисов, реализованный (техническим) решением (состоящим из различных подсистем и уровней).), которая включает в себя набор технических услуг.

...