24.3. Implementing the pattern
In order to represent the various information, we either need an embedded context or an enumerated role. Since we have rejected the notion of contract, we will use an enumerated role. However, the context being public, it must be an unlinked role (otherwise visitors would receive a representation of the context with all account roles, disclosing, at least, the number of accounts).
To protect the privacy of Accounts, its perspective on itself needs to be selfOnly.
In order to be able to see the context at all before an end user has established an Account, we need a Calculated role. This role must have a perspective that allows it to create an Account, that is, to initiate the process that leads to either a full account or its rejection. This we achieve with a Guest role that computes sys:Me.
Depending on the preference for enumerated roles over calculated roles, as soon as the Guest has created an instance of Accounts that is (ultimately) filled with himself, the Accounts type will turn up as the type of the role played by sys:Me in the Body context.
We then have three states on Accounts:
-
Waiting
-
Rejected
-
Accepted