智能合约的分层设计模型大多是参考一篇名为《浅谈以太访智能合约的设计模式与升级方法》的文章，“业务逻辑与外部解耦、业务逻辑与数据解耦”是Java设计模式的一种策略，也是文章中的主要思想。分层设计思路主要如下：
将合约拆分为代理合约、业务控制合约、业务数据合约、命名控制器合约。
其中代理合约是用于业务逻辑与外部Dapp的解耦，业务控制合约、业务数据合约和命名控制器合约是用于业务逻辑与数据的解耦。
作者在设计时，也拆分了几种不同的场景，详见如下：
- 控制器合约与数据合约1—>1:
- 控制器合约与数据合约1—>N:
- 控制器合约与数据合约N—>1:
- 控制器合约与数据合约N—>N:
层设计实现关键点
1. 合约与合约之间的调用
合约调用合约的实现主要有两种方式，第一种方式是可以通过 call、delegatecall、callcode方法实现对其他合约的方法的调用，但是其弊端是使用存在安全性问题，而且不能获知被调用合约的执行结果，不建议使用。第二种方式，是通过在合约中“外部引用”被调用的外部合约进行实现。
通过合约“外部引用”实现调用外部合约需要注意以下几点：
- 合约对象中需要定义被应用合约对象的方法，否则合约中无法识别被应用对象，编译器会报错
- 被引用对象需要通过合约对象的设置外部合约方法将合约对象进行引入，注意需要引入外部合约对象后
2. 合约与合约之间的转账
合约可以接收转账，需要显示声明回调函数，并在回调函数上加payable进行修饰。合约与合约之间进行转账时，需要在合约中显示用send或者transfer进行合约之间的转账，合约与合约之间的转账将以内部交易的形式执行。另外，在显示转账的方法中也需要加payable修饰。
分层设计的局限与问题
1. 被调用合约的方法的数据返回限制
被调用合约在返回string/bytes等不定长类型时会存在问题。这种限制需要在设计被调用合约时要注意，在实际项目中业务逻辑合约和数据合约都属于被调用合约，故而其设计公共方法时需要规避string/bytes等不定长的限制问题。
2. 被调用合约结构体数据返回限制
Solidity语言中，在编译器0.4.17版本之后，可以支持struct结构体的数据返回。在返回结构体的情况下，编码需要注意添加“pragma experimental ABIEncoderV2;”
3. 被调用合约的方法的返回参数长度限制
被调用合约在返回定长的数据时，不能返回超过32位长度的数据，例如bytes33/uint33编译器将会提示错误。
4. 被调用合约事件监听的问题
如果被调用合约需要触发事件，可能会存在事件监听的问题。如果通过web3j监听区块链的事件，被调用的合约事件信息可能会被编码，故而可能导致web3j无法监听到被调用合约内部触发的事件
5. 被调用合约返回合约类型的限制
被调用合约能够返回合约类型的数据，编译器将合约看成地址返回，而地址是定长的