Hi,
I've just refactored the email handling service, as it was doing four
things in one:
1) Create emails
2) Send emails
3) Receive emails
4) Create conversation responses
These are now in four separate services, one for each task. Two are
infrastructural (send/receive emails), whereas creating emails and
responses are application level services. They communicate by using
application events, which is a new concept.
Basically, it works like this. First you have the command-event chain:
command->domain->domainevent
Some of those events should cause emails to be sent, such as
receivedMessage on user. So there is a domain event consumer that
listens for this and creates application event "sentEmail(EmailValue)":
domainevent->service->applicationevent
The sentEmail event is more like a request of what should happen, so
then another service actually performs the sending, the SendMailService:
applicationevent->service
You can turn off the SendEmailService, and still have the application
events created. These can be read using a REST resource
/streamflow/events/application. So you could potentially have one server
consuming app events from lots of places, and then acting on them (e.g.
sending emails).
For receiving emails, it's almost the opposite:
service->applicationevent (receivedEmail)
applicationevent->service->command (addMessage)
command->domain->domainevent (addedMessage)
To make it easy to consume these services I've created some wrappers for
the replay functionality, so all of the above is in practice pretty easy
to do. Have a look at NotificationService for example.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
