Party 模式中的层次结构模型支持多种灵活的层次结构，但这里我们只要关心上下级的包含关系就可以了，参加结算的称为结算实体BalanceEntity， 不可再拆分的称为LeafEntity， 可以包含下级结算实体的称为CompositeEntity，因此在这里还可以支持一些象客户群，用户群这样的概念（一般没有那么复杂）。
从前面可以看到，代理商签有合同Agreement（如有多个代理商，合同内容可能相同也可能不同），在合同里面规定了不同的业务Business（汽车美容服务推广），每种业务的结算规则（BusinessRule，对应帐务模式中的PostingRule）各不相同，而结算规则作用在不同的服务项目（ServiceItem）上，因此，我们需要抽象出合同，业务，业务结算规则，服务项目，组成主要的模型结构。
为了从系统外部配置规则，我们同样还需要抽象出项目类别，规则类别和它们之间的关系（需要注意的是，项目从用户向客户汇总属于业务结算规则的一部分，还有最后的结算账目总额，也是规则的一部分，需要纳入配置）。同时，根据“范围”模式一文中的比例模型，这里有些规则需要用到比例，因此，它也需要加入模型。
具体的模型如下图所示：
如上图所示，虚线上面是基本的模型结构，下面是用来进行配置的类型和关系，其中的费用项目类别ItemType作为规则类别RuleType 的参数和结果；而RuleType 跟比例类别相关联，BusinessRule 的计算方法也在RuleType中指定。
在前面的例子中，系统初始化的时候，建立代理商，客户，用户（作为叶子实体）的结算实体结构，建立它们之间的关联关系，根据费用项目类型，初始化费用项目（包括所有的具体费用项目，高中低三档的费用累计项目，和所有费用累计项目，普通佣金项目，和VIP 佣金项目，佣金总和项目），费用项目容器，然后针对费用项目建立处理规则，和需要的比例（包括3 个固定比例：中档佣金比例，低档佣金比例，VIP 额外佣金比例和1 个范围比例：高档佣金比例）。
