I am comparing patterns of passing/using contractId vs contract Keys when creating associations between contracts. Example
a contract representing an “organization”: the org can create a “department”: the department uses a key or a contract ID of the org? (or there could be a party per org).
Is there some “real-world” recommendations on when to use one style vs another?
Considerations i have seen:
- Using the contractId means replacing the parent contract means the sub-contracts are invalid
- Using Party for each org means ever increasing number of Parties as a “role” style use of party.
- You could maybe get around arching the parent contract if you follow a strict separation of Data contracts vs “action”/role/code contracts as explained in: Role Pattern usage based on examples: User Template with choices vs choices on the sub-templates? - #2 by drsk
- It feels like any long term contract (such as contracts representing an “organization”) would be better suited using Keys to mitigate the potential of accidental archive of the contract
- ContractId feels better suited for transactional short term actions that are dependent on a specific state of the parent: such as a group invites a new member to the group, the Group may only want to honour the invites for the current state of the group: if the group contract changes then new invites would need to be established.