第一个。在订单数据表里面会有个最终优惠后的订单金额，那么这个计算优惠金额是应该订单服务来做吗？
商品的原价是多少，满减优惠了多少，特价减免了多少，优惠后的计算结果肯定是订单的一部分，也需要保存在订单服务里面。那计算优惠金额应该是订单服务来做吗。
这里，我们不难看出涉及有订单服务和促销服务，两个服务。
他们都是基础服务，基础服务是最底层的服务。各自提供了自身业务领域内的业务功能，订单服务提供跟订单数据相关的服务，比如订单列表，订单详情。促销服务提供跟促销相关的服务，比如促销规则，营销结果价格。
回到开头的那个问题，计算最终的优惠后的金额，是订单服务来做还是促销服务来做。
促销服务来做。
促销服务，作为一个独立的物理上的业务域他拥有各种各样的优惠规则和数据，如果把计算优惠最终的订单金额功能放到订单服务里面去，促销服务就要把这些很多种促销规则发送给订单服务，不但调用成本高，而且那些促销规则发生改变的时候势必会影响订单服务的内部实现。
服务的数据和职责要一致，谁拥有信息，谁就要负责提供相应的功能。
所以，促销服务负责促销规则的维护，以及对应的优惠计算功能。订单服务负责优惠结果数据的落地和后续的查询功能。
另外一个技术边界的问题是订单和商品。
我们都知道订单数据里面会有商品ID，那么当其它系统需要商品详情的时候，订单服务需要负责提供吗？
不会提供。这不是订单服务的职责，还是那句话，服务的数据和职责要一致，谁拥有信息，谁就要负责提供相应的功能。
如果需要订单的商品详情信息，可以在上层的应用服务里面去处理，通过聚合订单服务和商品服务来实现。
--《架构实战案例解析》
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。
