Can an aggregate issue its own commands?

Question

Question

Can an AR issue its own commands, or it is better to issue them through a processor that listen event emitted by the outer command?

BTW: If you consider that this question could lead to "primarily opinionated” answers, I would still want to know whether or not it is considered a good practice, and the why.

PHP code sample

class PatchableComponent extends EventSourcedAggregateRoot
    implements Entity, ReconstitutableEventSourcedAggregateRoot
{
    ...

    public static function importFromCore(...): PatchableComponent
    {
        $patchableComponent = new self;

        $patchableComponent->applyPatchableComponentWasImportedFromCore(
            new PatchableComponentWasImportedFromCore(...)
        );

        // Here, the AR issue its own startLookingForPatches() command.
        $patchableComponent->startLookingForPatches();

        return $patchableComponent;
    }

    public function startLookingForPatches(): void
    {
        $this->applyPatchableComponentStartedLookingForPatches(
            new PatchableComponentStartedLookingForPatches(...)
        );
    }

    ...
}

score 1 · Accepted Answer · answered Aug 08 '19 at 11:26

1

Can an AR issue its own commands, or it is better to issue them through a processor that listen event emitted by the outer command?

An aggregate can certainly call its own methods; adding extra layers of indirection is not normally necessary or desirable.

answered Aug 08 '19 at 11:26

VoiceOfUnreason

52,766
5
49
91

Do you have a blog where you're talking about DDD in general? I would like to read you about this particular subject ;) Most of your answers are very well written. Thank you some much for your time. That's much appreciated. – Laurent DECLERCQ a.k.a Nuxwin Aug 08 '19 at 11:32

CPerson · Answer 2 · 2019-08-08T17:27:14.373

1

I know there is an accepted answer for this question, but wanted to chip in my own 2 cents.

When you state that an Aggregate is issuing a Command, your code sample doesn't actually do that. Your example is that of an Aggregate performing certain behavior. The concept of a "Command" is that of a message that encapsulates a user's intent (Use Case). A Command would be typically (and hopefully) handled by a CommandHandler which would then call methods on the Aggregate to perform the work. The Aggregate doesn't really know about Use Cases.

If you separate the concept of the Command from the concept of the Aggregate then you are free to implement Behavior in a way that makes your domain flexible. You are able to add new Use Cases (Commands) and new Behaviors (in your Aggregate) independently of each other.

edited Aug 08 '19 at 17:27

answered Aug 08 '19 at 14:47

CPerson

1,222
1
6
16

Basically put, for you, a command involve CQRS, that is, a command handler. For me, a command is naturally provided by an aggregate which encapsulate a use case made available for the outside world or not... This command trigger a behavior. But I'm pretty new in DDD world so maybe my vision is erronous. – Laurent DECLERCQ a.k.a Nuxwin Aug 09 '19 at 16:31
1

That's fair and I don't perceive one way as being right or wrong, but there are benefits to separating the UseCases from the Domain model. As with all things, there are trade-offs and you would have to do the cost-benefit analysis to understand whether that layer of abstraction is worth it. – CPerson Aug 09 '19 at 19:26

Can an aggregate issue its own commands?

2 Answers2