Why are aggregates the command handlers?

[StephenGilboy]

Hi there. I'm just getting started with the framework, I'm coming from the C#/.NET world of DDD/CQRS. I am enjoying the library but I did have a question about why aggregates are handling commands and the reason for that?

---

.NET World

In .NET, from my experience, the CQRS is separated from the domain/aggregates.

  \domain\
     bank_account_aggregate.rs
     bank_account_events.rs
   \appllication\
     deposit_funds_command.rs
     deposit_funds_command_handler.rs
   \infrastructure\
     bank_account_repository.rs
     event_store.rs
   \api\
     bank_account_controller.rs

bank_account_aggregate.rs: implements all the business logic functions and emits events. It'll open the account, handle deposits, withdraw, etc... and then return events.

deposit_funds_command_handler.rs: Handles the deposit_funds_command.rs by using the bank_account_repository.rs to get the bank account from the data store then calls the deposit function on the aggregate and then handles emitting the returned event or error.

bank_account_controller.rs: Is the HTTP endpoint that receives/validates user input then creates the command to hand off to the command handler.

The benefits of this is that I can swap out any and all 3rd party dependencies, since the domain library should have no dependencies, and the business logic isn't cluttered with external calls since the aggregate has, either from it's state or from the function parameters, everything it requires to do what it needs to do.

---

Hopefully that helps set the context for my question. It wouldn't be too much work for me to pull the business logic out of the aggregate handler but I was I just want to know the reason for the aggregate being the command handler. Perhaps in your experience you've found the command handler isn't worth it or maybe it helps with Rust lifetimes. I'm not criticizing the choice I just want to understand the reasoning.

Thanks!

[davegarred]

deposit_funds_command_handler.rs: Handles the deposit_funds_command.rs by using the bank_account_repository.rs to get the bank account from the data store then calls the deposit function on the aggregate and then handles emitting the returned event or error.

This doesn't isolate the aggregate as much as we'd like. The problem here is that some business logic exists in deposit_funds_command_handler.rs, even if it is only a bank_account_repository->lookup(), and this violates DDD.

Business logic tends to grow over time, for instance if we added multiple currencies:

• We'll need another lookup for exchange rate.
• Do we convert before calling the function on the aggregate? If so what happens when that method of conversion changes (e.g., adding a service charge)? If not how do we pass the rate, is this a different function?
• For harder to obtain currencies, are there additional service charges from currency vendors? We'll need to look these up too.
• Do we need to chain currency conversions (e.g., USD -> GBP -> NGN)? How do we pass this information in, another function?

Very quickly we are doing a whole lot of business logic on the lookup side of things, we're no longer doing DDD right and we can't test any of this cleanly. In practice, I can tell you that these lookups change early and often in any software outside of a demo.

In short, even if the business logic for your lookup is simple now, it probably won't be in the future. It's best to do any needed lookups from within the aggregate. These lookups should be calls on your aggregate's Services associated type. This is where you'll want to make sure these calls are abstracted from any 3rd party dependencies, those only need to exist in your Services implementation.

[filwaline]

What about the relationship between aggregates? For instance, if AggregateA references AggregateB by ID, how can you retrieve AggregateB without an application-level command handler?

[davegarred]

You would never read from an aggregate, it is only there for write purposes.

If AggregateA needs some information about AggregateB then it should use one of AggregateB's views in it's 'Services' associated type.

[filwaline]

https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/
Inject out-of-process dependencies into the domain model — Keeps performance and domain model completeness, but at the expense of domain model purity.

It seems that your approch break domain model purity, because aggregate's handle has out-of-process dependencies.

Which one is better?
I strongly recommend that you choose domain model purity over domain model completeness, and go with the third approach: splitting the decision-making process between the domain layer and controllers. Domain logic fragmentation is a lesser evil than merging the responsibilities of domain modeling and communication with out-of-process dependencies.

What do you think about this?

[filwaline]

If AggregateA needs some information about AggregateB then it should use one of AggregateB's views in it's 'Services' associated type.

I thought that the "view" is a complete reading side thing, and the writing side should not depend on a "view"?

[davegarred]

To be sure, AggregateA would never use one of it's own views to make decisions. The needed information should be included within the aggregate.

It is quite common to read from external services when processing a command.