document eventhandling

[Metauriel]

Description

Links to Tickets or other pull requests

Changes

Datasecurity

Deployment

New Repos, NPM pakages or vendor scripts

Screenshots of UI changes

Approval for review

• All points were discussed with the ticket creator, support-team or product owner. The code upholds all quality guidelines from the PR-template.

Notice: Please remove the WIP label if the PR is ready to review, otherwise nobody will review it.

[alweber-cap]

Suggested change

	the event is in the end simply a class, containing any data required to handle the event
	The event is in the end simply a class, containing any data required to handle the event

[alweber-cap]

Suggested change

	note that the handler should not contain any logic, but only the orchestration of what needs to be done.
	Note that the handler should not contain any logic, but only the orchestration of what needs to be done.

[virgilchiriac]

Suggested change

	If you are implementing an operation in a module that needs to trigger an operation in another module, that is simple if you can simply import a service. However, if that other module already has a dependency on your module, that would lead to a dependency cycle. In this case, you need to inverse one of the dependencies via events.
	If you are implementing an operation in a module that needs to trigger an operation in another module, you can simply import the service in your module.
	However, if the other module already has a dependency on your module, that would lead to a dependency cycle. In this case, you need to inverse one of the dependencies via events.

[virgilchiriac]

Suggested change

	The main thing you need to think about, is which module should know about which module(s). This is the dependency, and it only ever can point into one direction. As a general rule of thumb, the module that is more specific, or is changing more frequently, or is less central to the functionality of the system, should have the dependency on the other.
	The main thing you need to think about, is which module should know about which module(s)?
	This is the dependency, and it can only point to one direction.
	As a general rule of thumb, the module that is more specific, or is changing more frequently, or is less central to the functionality of the system, should have the dependency on the more stable one.