Aggregate Creation Patterns

[ess-cdp]

Good afternoon,

My questions boil down to the following:

1. If an aggregate can be created different ways, should I expose that via different command and event pairs?

2. If an aggregate is sometimes created through mapping, should that mapping be done in the aggregate or should it be done in the command handler just before passing the mapped entity to the aggregate?

3. If I am using one single "Created" event, then can/should multiple sagas subscribe to the same event?

The details:

I have an aggregate, Payment, that represents a customer payment. A Payment can be created one of several ways: import, manual, etc. Creating it via import is part of a saga and usually involves mapping from an imported data format. Other ways might be part of other sagas. Currently, I have command and event pairs for each way that a Payment can be created:

CreateFromImport -> CreatedFromImport

CreateManually -> CreatedManually

In the first command, the Aggregate takes the data in the import format and maps it to the internal root entity. It doesn't seem scalable, but different sagas then listen for those distinct events and I wasn't sure whether different sagas should be listening for the same event even though only one of them will actually process the event:

CreateFromImport -> Created

CreateManually -> Created

One last option is: 

Create -> Created

In the last case, the mapping from some external format to the root entity would be done in the CommandHandler and passed into the Payment aggregate. In this last approach, the Payment aggregate would not be responsible for mapping and the CommandHandler would have more logic than is ideal. 

So, fellow CQRS architects, how do you tackle this problem?

[Herman Peeren]

Do you create payments in your domain? That would be profitable business ;-)

I'd start modeling the process and find the words used in that process "in the real world". Who is paying for what and how? What can go wrong and what happens then? I guess the word "create" is not needed then. It could help to talk about it with a non-technical person with some knowledge of the domain.