What functionality belongs in DAML models versus application code?

The answer to this question depends on how you’re using your ledger and what is important to you. Consider two different use cases: a ledger encoding legal rights and obligations between companies versus using a ledger as a conduit for internal data synchronization. Each of these solutions would be deployed in very different environments and are on either end of the trust and coordination spectrums. Internally to a company, trust is high and the ability to coordinate change is high. External to a company, the opposite is true.

The rest of this page will talk about how to organize things in either case. For your particular solution, it is important to similarly identify the what factors are important to you, then separate along those lines.

Looking at the ledger from a data synchronization perspective

On the other hand, when doing data synchronization most of the inter-process communication between parties belongs on the ledger. This perspective is grounded in the fact that DA’s platform acts as a messaging bus where the messages are subject to certain guarantees:

  • The initiating party is authentic
  • Messages conform to DAML model specification
  • Messages are approved by all participants hosting stakeholders of the message

Therefore, when doing data synchronization all of the above functionality is eligible to go into the DAML models and have the application be a lightweight router. However, there are still some things for which it isn’t sensible to put on the ledger. For examples of these, see the section on DAML anti-patterns.