Skip to content
This repository has been archived by the owner on Jun 22, 2022. It is now read-only.

Policy #10

Closed
3 tasks done
ryan-mars opened this issue May 4, 2021 · 2 comments
Closed
3 tasks done

Policy #10

ryan-mars opened this issue May 4, 2021 · 2 comments
Labels
event-storming Fluent components for translating event storms to code
Milestone

Comments

@ryan-mars
Copy link
Owner

ryan-mars commented May 4, 2021

Policy

Software Model

Illustrations ©️ Avanscoperta

@ryan-mars ryan-mars added this to the Demo milestone May 4, 2021
@ryan-mars ryan-mars mentioned this issue May 4, 2021
14 tasks
@sam-goodwin
Copy link
Contributor

Is there a snippet from the event storming material we can include here, like we did for Bounded Context #7? I thought that was especially helpful.

@ryan-mars
Copy link
Owner Author

Policies are probably the most interesting thing to model in EventStorming. They cover all the spectrum of organisation reactions from human behaviours to automation including:

  • habits
  • unconscious reactions
  • Tacit agreements
  • Explicit agreements
  • Codified or corporate rules
  • Inconsistent rules (different actors implementing the same rule in different ways)
  • Listeners (stateless listeners performing easy tasks, like sending notifications)
  • Process Managers and Sagas

The link between an event and its consequences can be encapsulated by a policy, but when the event-reaction combination is too obvious, we might miss the link.
Forcing ourself to obey the rule:
There has to be a lilac between the orange and the blue
...is a good way to force yourself into asking deeper questions about the nature of the policy.

@ryan-mars ryan-mars added the event-storming Fluent components for translating event storms to code label May 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
event-storming Fluent components for translating event storms to code
Projects
None yet
Development

No branches or pull requests

2 participants