Closed AlexandreRoba closed 10 years ago
Hi Alex,
Normally you're right :-) But to have nice arguments (https://github.com/adrai/cqrs-sample/blob/master/domain/businessRules/itemBusinessRunes.js#L4) in the business rules the apply function saves the "pre"-applied values (https://github.com/adrai/node-cqrs-domain/blob/master/lib/bases/aggregateBase.js#L108) and if the business rules fails it will revert them (https://github.com/adrai/node-cqrs-domain/blob/master/lib/bases/aggregateBase.js#L150)
Is it understandable? ;-)
Thanks for the answer. I can see the advantage(s) when using a separate set of rules. It is way easier (like you did) to define your rules on a "temporary" or "pre" Aggregate state. The business rules are far more readable the way you did it. I'm just concern about the errors that might be raised while applying the event whitout validation such as (Divide by zero or Overflow)...
According to your experience splitting your business Rules or validation rules out of your aggregate did brang a lot of value? I like to keep those rules with my aggregate operations. I have the feeling the code is easier to read and to test. such as a way I do not need to load my aggregate using the aggregate loader etc for my test. My aggregate is kind of complete. What was the "TOP" reason for taking those validations rules out of the aggregate? Reusability?
Thanks a lot for your help.
When I code the events in the aggregates I always handle the event applying part as "just" save some values... never to special logic... this logic parts should go to the "command" part of the aggregate.
My modules are used in different projects... in the first bigger project there was a need to have a possibility to extend the business rules (for customization)...
I see the point :) But this business Rules customization part... Isn't it very very dangerous? Do you mean customization while developing the project and before having any data in the system? or customization afterward while the application is up and running? If a new rule is added after... It will be applicable to the previous events that might not comply to this rules anymore...What will happen when you will "Apply" the history... Shouldn't you instead define new version of the Aggregate operation with the new rules instead? I can see that you have this case on your sample... Should'nt be this the way to go for adding new rules?
while developing... ;-)
PS. Applying the history will never validate or check the business rules...
PSS. a fifth argument is passing to obtain the version of the aggregate... (https://github.com/adrai/node-cqrs-domain/blob/master/lib/bases/aggregateBase.js#L133)
Thanks for those clarification.
Indeed Reapplying the Events should never call the validation :)
I'll keep digging on module. I'll keep you posted of my findings.
Dear adrai,
I'm looking at your implementation of cqrs (cqrs-domain) and the current sample. I've done couple of CQRS application in C#. I'm pretty new to Javascript and I'm starting to find my way in.
I have a question regarding your sample. When you look at the item aggregate operation, the apply operation is always called before the check business rules. Once the apply is completed, then you check for the business rules.... doesn't this is implemented in the reverse order? Shouldn't you first check the business rules before applying the changes? You could imagine the case where the information in the event might cause the apply to fail. From my experience in CQRS an Apply should never fail unless system errors.
thanks for the good work.
Alex.