SOA 服务边界和生产支持

Question

我们的开发小组正在努力建立服务目录。

目前，我们有两个小组，一个负责销售产品，另一个负责为该产品提供服务。 我们有一项特定的服务可以计算产品的价格是否有利可图。当销售发生时，销售可以被经理覆盖。此销售还必须在另一个系统中表示以跟踪各种销售，并且数字必须匹配。盈利能力的参数也会发生变化，并且每个月都不同，但销售可能基于之前的一组参数。

目前销售盈利服务只计算利润，它还提供了一个 RESTful URI。

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

那么，如果一个服务适用于一个狭窄的切片，但基于异常的业务流程破坏了它，这是否意味着服务的边界不正确并且需要考虑业务流程的变化？

二，添加日期参数是否过多地扩展了服务的边界，还是应该例外，如果服务已经有参数，它也会有参数的历史？目前，我们没有只存储参数的服务，因为没有人需要它。

如果在给出答案之前需要任何澄清，请告诉我。

Answer 1

我认为这里的关键是：如果在两个团队之间引入 ETL，那么两个团队会承受多大的痛苦？

并不是我认为您对此进行了过度分析，但如果我可以的话，您可能认为在服务合同中添加日期参数是不好的，但也不喜欢 ETL 的想法。

好吧，抛开策略不谈，我发现这些天来我最重要的本能是减少对技术细节的关注，而更多地关注纯粹的实用性。

归根结底，ETL 简单、可靠且实施起来相对轻松，但它也有副作用。主要的一个是您将与外部方耦合对服务的数据库模式的更改，这将限制将来发展您的服务的选项。

另一方面，让消费者需求决定服务发展既简单又低摩擦，但也是一条崎岖不平的道路，因为您可能会以牺牲其他人为代价来感谢该消费者。

另一种可能性是允许通过message 将额外的服务参数传递给消费者，而不是通过同一个服务。这将允许您保持服务边界完整，并让消费者将必要的参数保存在他们自己的本地。

如果这不能直接解决您的问题，我们深表歉意。