1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
use crate::;
use Result;
/// Provides read-only access to domain state for a `Policy`.
///
/// `PolicyContext` exists to support the evaluation of policies in response
/// to domain events. It grants read-only access to repositories or domain
/// views, allowing policies to determine follow-up behavior (e.g., additional
/// commands or projection messages).
///
/// Unlike a `UnitOfWork`, this context must not allow any mutation of domain
/// aggregates or emit events. It is created once per domain event and discarded
/// after the policy has completed.
// NOTE: The use of `Context` here isn't exactly correct. A Context
// type should not have access to a repository. However, for our purposes,
// we're going to use this until we can determine a more accurate name/pattern.
/// A stateless rule that reacts to domain events.
///
/// `Policy` types define declarative, stateless business logic that reacts
/// to domain events and produces a set of downstream side effects, such as
/// new commands or projection messages.
///
/// Policies must not modify domain state. They are evaluated using a
/// `PolicyContext` that provides read-only access to domain data. The
/// returned messages will later be published to the broker by the message
/// bus, where they can be handled by a command handler or a projector.
///
/// Policies are often used to express cross-aggregate or workflow rules
/// that arise as consequences of a domain event.