opened
rahulrai-in
username_0
The guidance does not say anything about operations that require reading historical data and then making decisions in aggregates. For example, handling a hypothetical case where a customer can't place more than N orders of a certain product across all the orders that they have placed.
How to handle operations that require loading historical data
issue
created
mvelosop
username_1
Hi @username_0,

That should be handled in the validation behavior in the MediatR pipeline, although currently the handling of the validation result has to be improved A LOT 😔.

You might want to take a look at some experiment I did sometime ago regarding this topic here: https://github.com/username_1/Microflow-X/blob/master/src/Tenants/App/Behaviors/ValidatorBehavior.cs

Hope this helps.
comment
created
rahulrai-in
username_0
Apologies if the details that I provided was not sufficient. I do have validators in my pipeline and I only perform basic type validations in the validators e.g. verify that a field has value or that length is less than n characters etc.

Currently, I execute validations that require querying historical data e.g. existing orders in my command handlers and hence I segregate validation issues with data that violates business constraints. However, I am not sure whether this is the ideal approach as business validations are the responsibility of aggregates and entities and I am pushing those responsibilities to command handlers.

From what I can understand from the eshop sample, aggregates and entities can only apply business logic on the active record e.g. a single order record. However, this sample lacks guidance on what if an order record needs to execute some business logic based on whether there is another order for the customer in the database.
comment
created
mvelosop
username_1
Hi @username_0, there are some nice insights there!

You can actually add anything to validators, say by injecting the required repositories like here: https://github.com/username_1/Microflow-X/blob/master/src/Tenants/App/Validators/AddTenantCommandValidator.cs

What I'm currently doing (not actually in the above repo) is to have validators in the domain project even though executing the validations is performed in the application project. As you mention, I also think the validation details belong to the domain, and the application project just coordinates all pieces, without having to know that detail level.

About the last paragraph, what I'd currently do, is tackling that in the corresponding command handler and perhaps call a different entity.method or adding another parameter to the method call.

I've even thought that command handlers should be in the domain project and raise domain events to trigger any domain related actions but haven't actually implemented any app this way, so I have yet to check the results to see how it feels.

Hope this helps.
comment
created
mvelosop
username_1
Closing this issue now, but feel free to comment, will reopen if needed.
comment
closed
mvelosop
username_1
issue