写到这个的时候，很多财务方面的人员就会站出来了。

每到月底的时候，核算的时候，五万的额度对不上不是问题，五千的也不是问题。但是碰到说，你还有一分钱账对不上哦。完了，心里一万只*奔腾而来。
自己手工算账的时候，出现这样的问题，那只能怪自己不专业的行为。但是现在把这种专业的行为交给专业的ERP软件去进行核算，你还给我时不时出现，你这软件有没有问题哦。

应用与反思

今天碰到一个这样的业务问题。

业务员在做一张采购订单的付款计划的时候，要跟踪当前采购单据的付款进度，要根据多个维度来区分。有的合同签订的时候需要首先交付30%的预付款，剩下的70%才有入库后进行实付。那对于奇怪的总金额，计算的时候，按30%的比率掰扯以后，就出现的余额小数。

需求人员说，有的时候客户想填个金额，你也给我反算一下比例来吧。好，开发人员照办，给比例与金额加了个互算。这样就会成了一个循环，比例-金额-比例-金额.... 最后就形成了如图，明明五五开的一个付款条件，最后因为互算逻辑，导致了超过100%。

搞笑的是，需求人员认为，这个需要开发再继续控制，再填写最后一行的时候，应当采用用100% - 前面所有行之和，这样就能保证了比例100%的情况。

（大爷，你自己加的逻辑啊，要金额互算比例，那万一客户改了呢？治标不治本。）

说这么多，我觉得最开始就是设计存在一个问题。业务员应该更关心的是这张付款到了哪一步吧，是不是按照计划进行的，无论是按比例还是金额，业务关心的是一个维度吧。 比如按比例，财务付款单付了就回填金额，然后根据根据金额，显示比例计算就OK，就不用处理财务计算了。

ValueObject

也就是只用一个维度，另外个维度不做互运算。其实就是值对象中重要的，清除ValueObject之间的双向关联。

值类型是用来描述领域某个方面而本身没有概念标识的对象

它有几个特点：

• 它是不可变的，不需要唯一标识；
• 只关心是什么，不用关心它是谁；
• 可以是一个集合，也可以是一个实体Entity；

我们在考虑值对象的时候，应该尽可能从它的几个特点出发，它是对实体的一个描述，并且减少双向关联，才能尽可能做到低耦合的特点。