Add framework documentation #33
Conversation
|
|
||
| _Command_ or _business operation_ or _interaction_ or _use case_ or _application service_ (DDD term) even just _service_ (this term is so ambiguous) is a predefined sequence of programmed actions that can be called by a user (directly in the code or via the API) and modifies the application state. In the scope of this framework, we prefer the _operation_ term though. | ||
|
|
||
| These modifications are atomic in the sense that the application state is supposed to be consistent and valid after the operation execution. It might be eventually consistent but the idea is that the application state is valid after the operation execution and in a normal case, there should be no need to call a complimentary operation to make the state valid. |
There was a problem hiding this comment.
I believe you are using atomicity and consistency interchangeably in here. They are seperate properties, both of them are wanted in the Operation.
There was a problem hiding this comment.
I don't understand your point tbh. Can you propose a way to rephrase this paragraph please?
There was a problem hiding this comment.
From a DBMS background, Atomicity means that your transaction either happens or doesn't happen. Consistency means that things like referential integrity are enforced.
We would like the transactions (in this case, operations) to rollback the changes if an operation failed midway, and thus atomic. The consistency aspect is more concerned with the state of the "system" before and after a transaction.
This sentence These modifications are atomic in the sense that the application state is supposed to be consistent and valid after the operation execution describes consistency, not atomicity.
There was a problem hiding this comment.
Atomicity also means that a bunch of changes happen at once, it can't happen partially and thus it keeps the application state consistent afterwards. I don't understand your point tbh. I think I used it correctly. The sentence describes both. There is a way of doing non-atomic changes but then the app state is not going to be consistent after each change.
| rule do |context:| | ||
| params_key = :"#{name}_id" | ||
|
|
||
| next key.failure(:key?) unless key?(params_key) && context[context_key] |
There was a problem hiding this comment.
Having some difficulty understanding this line. How exactly is next going to work in this context?
There was a problem hiding this comment.
| 2. Check policies | ||
| 3. Check preconditions | ||
| 4. Validate user input | ||
| 5. Call operation if everything is valid |
There was a problem hiding this comment.
what about callbacks ?
There was a problem hiding this comment.
Callbacks are irrelevant in this case and will just confuse.
Co-authored-by: radekzawada <radek_zawada@op.pl> Co-authored-by: Mohamed Ashraf <mohamed.ash.roshdy@outlook.com> Co-authored-by: Nicolai Stoianov <stoianovnk@gmail.com>
No description provided.