Database Contracts

These are used only as data storage. The only logic they need is functions that allow other contracts to write, update and get data, and some simple way of checking caller permissions.

Controller Contracts

These contracts operate on the storage contracts. In a flexible system, both controllers and databases can be replaced by other, similar contracts that share the same public api(although this is not always needed).) Controllers can be advanced, and could for example do batched reads/writes, or read from and write to multiple databases instead of just one.

Contract Managine Contracts (CMCs)

The purpose of these contracts is only to manage other contracts. Their main tasks is to keep track of all the contracts/components of the system, handle the communication between thses components, and to make modular design easier. Keeping this functionality separate from normal business logic should be considered good practice, and has a number of positive effects on the system.

Application Logic Contracts (ALCs)

Application logic contracts contains application-specific code. Generally speaking, if the contract utilizes controllers and other contracts to perform application specific tasks it’s an ALC.

Utility Contracts

These type of contracts usually perform a specific task, and can be called by other contracts without restrictions. It could be a contract that hashes strings using some algorithm, provide random numbers or other things. They normally don’t need a log of storage, often have few or no dependencies.

The rationale for this division will be laid out after we’ve tried to apply it to the fund manager system, as it will be a lot more clear then.