供应链物流结算服务，需要支撑不同物流服务中不同费用的结算

清关

    清关税

    清关费

运输

    大件

    小件

仓储

    仓租

    操作费

再往细看，每一种费用还分为多种订单类别：

    成品

    行政采购原材料

    非行政采购原材料

    委托发货

    备件

一套系统要支持不同的这么多业务场景，肯定不能没头没脑的写if-else，只能依靠配置。根据自己的经验，参考网上的资料，暂时总结几点做配置要考虑的事项：

从业务事实出发，较真每一个概念、术语

越做方案越发现架构师讲的一句话“怎么架构都没有错”，如果我们自己创造了一些概念，跟业务讨论的时候我们一顿还侃，业务可能就会认同我们的方案，并且觉得我们很“专业”。但这只是看起来“专业”，实际上是在挖坑。系统真正要做的，是固化业务脑海中的逻辑，而不是我们造出来的逻辑。当然更牛的是引领业务优化逻辑，但首先要了解业务逻辑吧。

通过抽象/分层减少配置

配置是需要人去做的，其实不仅是业务希望配置简单，我发现开发也希望配置少一点，这样业务就不会因为配错来找开发看BUG......但是业务本身是复杂的，那就要按照金字塔原理进行分层，这样配置项会变少，而且更容易理解。当然配置表会变多，没有办法，业务本身就是复杂的，只能尽量按照业务脑海中的逻辑拆分，这样可以降低学习成本，而且更正确。

MECE，不重不漏

这个没什么好说的，尽量分析更多场景，每种场景分析全。

不要有完美主义，小众场景单独处理

加入999条都是选项A，只有1条是选项B，你还会在配置中加一列吗？

"千人千面"与"工作量"是矛与盾

毕竟我们不是做SaaS的，如果要考虑所有场景，势必要更多工作量。从实际出发吧，以解决业务问题为主，写死或用单独的快码吧。有时候会在系统中看到考虑的很好的设计，但是根本没用过。

不过在用户体验上应该加强，比如在页面上增加备注，用文字描述隐含逻辑，让业务更容易理解。