SOA服务边界和生产支持

Question

我们的开发团队正在努力与服务目录建立。

现在，我们有两个组，一组到产品销售，另一种以服务产品。 我们有一个特定的服务来计算产品的价格是否有利可图。销售发生时，销售可以由经理覆盖。此次销售也必须在另一个系统中有所体现，以跟踪各种销售情况并且数字必须匹配。盈利能力的参数也是变化的，并且每个月都有所不同，但是销售可以基于之前的一组参数。

眼下销售利润率服务只计算利润，它也提供了一个RESTful URI。开发商

一组建议，盈利服务还支持这些“经理覆盖”，并支持基于以前日期的日期参数来计算。当然，开发团队的销售人员不同意。如果服务不支持这一点，那么服务开发人员将不得不在两个系统之间为每个产品执行ETL，而不仅仅是利润服务。现在，由于我们没有一套服务来处理这个问题，所以生产支持获得了请求，然后必须更新与给定产品关联的1+系统。

所以，如果一个服务适用于很小的一部分，但一个例外基于业务流程打破它，这是否意味着服务的边界是不正确的，需要考虑业务流程的变化？

二，不添加日期参数延长了服务的边界太多，或者是否应该例外，如果该服务已经拥有的参数，它也将有参数的历史呢？目前，我们并没有一项只存储参数的服务，因为没有人需要它。

如果有需要可以给出答案之前，任何澄清，请让我知道。

Answer 1

我认为这里的关键是：多少痛苦的人会通过，如果和ETL之间被引入到两个两队将发生？

不是我认为你过分分析了这一点，但如果可能的话，你可能会认为在服务合约中添加日期参数是不好的，但也不喜欢ETL的想法。

好吧，抛开战略，我觉得这几天我的首要本能是不太注重技术来龙去脉，更对纯粹的实用。

在这一天结束时，ETL是简单的，可靠的，且相对无痛苦来实现，但是它带有的副作用。主要的一点是，你会将变更与你的服务的数据库模式结合到一个外部方，这将限制选项在将来发展你的服务。另一方面，允许消费者需求决定服务发展是容易的和低摩擦的，但也是一条崎岖的道路，因为您可能会牺牲其他消​​费者而屈服于该消费者。

另一种可能性是允许额外的服务参数通过message被交付给消费者，而不是在同样的服务。这将允许您保持服务边界的完整性，并让消费者保持本地的必要参数。

道歉，如果这并不直接解决您的问题。