Intermingling commands and aggregates is not proper cqrs, ddd, event-sourcing. Commands should adhere to general DDD principles, meaning a Command should be able to be so arbitrary that it doesn't fit underneath the umbrella of an "Aggregate" which should be nothing more than ... yep, an aggregate (a projection of a single stream). To really drive my point home is the fact that the result of a Command could be that more than one stream (aggregate) could have an event linked to it. Commands and Aggregates should be absolutely separate. Aggregates should be aware that events exist at a given stream name and how to process them (reduce!). Commands should be able to publish events, that's it.
Hey, yes you are right, commanded is definetely quite opinionated. To be honest I feel if someone is new to ES/CQRS using a highly opinionated framework might be useful as the risk of doing architectural mistakes decreases. However totally with you that there are a few shortcoming with how commaneded handes everything. The fact that aggregates cannot subscribe to events they don't publish can be highly limiting, and I've encountered that almost every time I've used commanded.
That being said there will never be a perfect framework for anything, especially something quite abstract as ES/CQRS, and commanded does a great job of making such architectures within reach and a "safer" risk to take when someone is building a startup and want to try out ES/CQRS
@Calvin Fong Definetely num 2. If you just need to guarantee that the email get's send you probably want to have an event handler that reads MoneyDeposited{}, and sends the email. This might mean that you need to create projections where the account information lives, so it can be accesible in the database. Now that makes it so that sending the email is *not* part of you core domain. Meaning that email is just a funtional sideeffect. (although it can happen that the e-mail is part of the core but that would be very rare usecases, where one might be legally required to send an email before doing further actions). With that you can see that not everything needs to go throught the "command -> aggregate -> event" architecture, sideeffects and things that are not part of the core business (like keeping track of money movement) should be separated
Intermingling commands and aggregates is not proper cqrs, ddd, event-sourcing. Commands should adhere to general DDD principles, meaning a Command should be able to be so arbitrary that it doesn't fit underneath the umbrella of an "Aggregate" which should be nothing more than ... yep, an aggregate (a projection of a single stream). To really drive my point home is the fact that the result of a Command could be that more than one stream (aggregate) could have an event linked to it. Commands and Aggregates should be absolutely separate. Aggregates should be aware that events exist at a given stream name and how to process them (reduce!). Commands should be able to publish events, that's it.
Hey, yes you are right, commanded is definetely quite opinionated. To be honest I feel if someone is new to ES/CQRS using a highly opinionated framework might be useful as the risk of doing architectural mistakes decreases. However totally with you that there are a few shortcoming with how commaneded handes everything. The fact that aggregates cannot subscribe to events they don't publish can be highly limiting, and I've encountered that almost every time I've used commanded.
That being said there will never be a perfect framework for anything, especially something quite abstract as ES/CQRS, and commanded does a great job of making such architectures within reach and a "safer" risk to take when someone is building a startup and want to try out ES/CQRS
@Calvin Fong Definetely num 2.
If you just need to guarantee that the email get's send you probably want to have an event handler that reads MoneyDeposited{}, and sends the email. This might mean that you need to create projections where the account information lives, so it can be accesible in the database.
Now that makes it so that sending the email is *not* part of you core domain. Meaning that email is just a funtional sideeffect. (although it can happen that the e-mail is part of the core but that would be very rare usecases, where one might be legally required to send an email before doing further actions).
With that you can see that not everything needs to go throught the "command -> aggregate -> event" architecture, sideeffects and things that are not part of the core business (like keeping track of money movement) should be separated