Common patterns (or anti-) for Data vs Contracts?

Hi

was looking if there was common patterns for usage of data vs contracts? The common example i have come across is usage of State within a contract such as mentioned in the now removed “anti-patterns” section of the docs:

Anti-patterns — DAML SDK 1.1.1 documentation.

I am wondering if there are other notable/common patterns that have come up as “use data instead of additional contract templates” and/or “use contracts instead of additional data”

Thanks!

As an additional example: In the Expense Pool example, the Pool holds a list of IOUs:

digital-asset/ex-models/blob/ca6818c10923360f7158e03a4c50dabe156f5419/expense-pool/daml/ExpensePool.daml#L29

      
        

            
    owner : Party
            
    amount : Decimal
            
    currency : Text
            
  where
            
    signatory issuer
            

            
template Pool
            
  with
            
    participants : [Party]
            
    name : Text
            
    ious : [Iou]
            
  where
            
    signatory participants
            

            
    choice Invite : ContractId PoolInvite
            
      with
            
        participant : Party
            
        newParticipant : Party
            
      controller participant
            
      do
            
        assert $ elem participant participants
        
      
    

Would not this qualify as an example where it would have been better to store a Pool Contract ID in the IOU vs storing the IOUs in the Pool?

StephenOTT:

Would not this qualify as an example where it would have been better to store a Pool Contract ID in the IOU vs storing the IOUs in the Pool?

I think it would not qualify as an example. I can say that based on Split: [ContractId Iou]. The existence of that seems to imply that Iou is being used purely as an almost prototypical data container. Moreover, it explicitly enables various workflows where the Pool does not have signatures to create the Ious, as those signatures can be gathered later, and need only be present when Splitting.

I go over a similar example here, where it is clear that it would be wrong for the contract to exist, even though all its data is present and packed into a payload. The presence of Pool in PoolInvite is very much like this.

I think this is why we don’t have the antipatterns page anymore. To be sure, there are right ways and wrong ways to do things in Daml, but when too much domain-specific judgement is required, documenting a bright-line rule can be…an antipattern.

StephenOTT:

I am wondering if there are other notable/common patterns that have come up as “use data instead of additional contract templates” and/or “use contracts instead of additional data”

As such, the rule here is really “use contracts for contracts, and use data for data”. For what it’s worth, the previously linked post has several examples where using an associated record type from a template is the right choice, and using a contract ID would be wrong. But I determined these examples based on how they were being used.

@Stephen Thanks for the details. The begging questions for me around contracts vs data arrive when thinking of the end to end usage: Contract creation to eventually inspection/reporting. I have see multiple recommendations in the forum around “use this pattern” because reporting becomes/is easier / less work. (compared to storing data in some circumstances)