Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Difference between CQRS command and message
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  1 message - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
雪华 汤  
View profile  
 More options Jan 18 2012, 2:48 am
From: 雪华 汤 <txh_...@163.com>
Date: Tue, 17 Jan 2012 23:48:49 -0800 (PST)
Local: Wed, Jan 18 2012 2:48 am
Subject: Difference between CQRS command and message
In the CQRS architecture, i have several problems/ideas(about how to
implement inter-aggregate communication) which has struggle to me
several months and eagerly want to discuss to you.

For short, i have the following problems/ideas:
1. Aggregate(AG) will communicate with each other in some times(e.g.
Money Transfer), but always use the publish-subscribe way, not the
request-reply way;
2. I think the concept of command and message is totally different.
command represents what user want the system to do, and the message is
used by the system communications, like the inter-aggregate
communication; Also take the money transfer for example, suppose there
is an TransferMoneyCommand, the command handler will first get the
source bank account from repository and call its SendMoneyTo method,
then the source bank account aggregate will generate the MoneySent
event and will be published by the event bus, then the event handler(a
saga if necessary, if you want to insure the whole process correct of
money transfer.) will send a ReceiveMoneyFrom message to the message
bus, then the message handler will get the target bank account from
repository and call its ReceiveMoneyFrom method. In this process, i
think we can not replace the ReceiveMoneyFrom message to
ReceiveMoneyFrom command, as they are different concept. A command
means that it can be issued by user, but a message means that it can
not be issued as it is used between system communication itself.
Suppose user can issue a ReceiveMoneyFrom command independently to the
system, how strange is that! For user, the TransferMoneyCommand is
meanful, but the ReceiveMoneyFrom is useless. So, in a word, i think
we should use the message to communicate between aggregates, although
the technology implementation of message/message handler and command/
command handler has no difference.
3. There are two logics: 1) domain logic; 2) process logic; the domain
logic is in the aggregate, and the process logic is in the event
handler/message handler/command handler/saga; right? So from this
point, what the * handler do is the same as the standard eric DDD's
application layer do. right?
4. Last question, i see that somebody said that we can not call the
aggregate directly in the event handler, because if we do that, we
will lose the intent of what we do. A command or message represent the
intent of what the user or system want to do. My question is, why we
can not represent the intent if we call the aggregate handler directly
in the event handler, i feel that in most cases this way is more
simple and direct and meaningful. What's your opinion?


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »