I'm looking for advice on aggregate-roots and commands.
Given the following command:
public class SetNewPriceCommand
{
public Guid Id { get; set; }
public decimal PriceValue { get; set; }
public string PriceIsoCode { get; set; }
}
I learned that domain-objects like aggregate-roots should not directly hande commands. If the app receives a command it has to transform the contents of the command like ids, price-value, price-currency on the application-layer (web-api) to domain-objects like ArticleId and Money. These values should then be passed to the loaded aggregate-root's method as parameters.
public class Article
{
...
public void SetNewPrice(Price price)
{
// validate if price can be set
// apply change
}
...
}
At work the current way we program aggregate-roots differently. Aggregate-root methods get their commands directly as a parameter.
To me this seems plain wrong, because
commands are just simple DTOs, containing only basic value types and no domain-objects like value-object or the like. I think converting transforming a command (or better said its contents) to domain-objects should be done on application-layer, not inside the domain.
public class Article
{
...
public void SetNewPrice(SetNewPriceCommand command)
{
// validate command
// validate if price can be set
// map command
}
...
}
As a team we are trying to update our current coding guidlines so this would be a chance to change this, but there is sceptism if not directly passing the command would result in more code et cetera.
I'm trying to find some arguments - pros and cons, even for both ways.
What I want to ask you
Is it considered "acceptable" to pass commands directly to aggregate-root methods?
- If yes, why? (and could you provide some (renowned?) sources)
- If no, why? (and could you provide some (renowned?) sources too)
Thank you in advance!