Interface design principles

Are there any thumb-rules / best practices / principles for designing interfaces in Daml?

One specific instance where some guidance will help is this.

Let us say, a bank creates Savings and Checking Accounts. For that we create an interface IAccount with viewtype AccountView and have two templates -Savings and Checking implement this interface.

Both types of accounts have the following fields:

  • custodian:Party
  • owner: Party
  • id: Text
  • balance: Decimal

There may be other fields specific to account-type, e.g. interestRate in savings account, minimum balance in checking account, etc.

Putting all common fields in AccountView gives the ability to query and see the field values at an interface level. However, it may hinder future development if we need account types that may not have/need all those fields.

So the question is how to decide which fields should go in AccountView vs. in Savings and Checking templates?

Will really appreciate some suggestions and any other best practices in this context.

Regards
Neelam

1 Like

When interfaces were designed, they had two goals: to facilitate extensibility and also upgradability. The example you give above is more related to the former; although I won’t address that, I would also encourage you to consider how interfaces can be used for facilitating upgradability.

This isn’t currently documented very well, but you can have a look at this part of the daml-finance documentation that explains how interfaces are used in the library to provide a limited form of ‘no downtime’ upgradability.

1 Like