我们的开发小组正在努力建立服务目录。
现在，我们有两个小组，一个是销售产品，另一个是服务该产品。 我们有一项特殊的服务，可以计算产品的价格是否有利可图。当销售发生时，销售可以被经理覆盖。此销售还必须在另一个系统中表示，以跟踪各种销售，并且数字必须匹配。盈利能力的参数也会发生变化，每个月都有所不同，但销售可能会基于之前的一组参数。
目前，销售盈利服务仅计算利润，它还提供RESTful URI。
一组开发人员建议盈利服务也支持这些“经理覆盖”，并支持根据前一日期计算的日期参数。当然，开发商的销售团队不同意。如果服务不支持此服务，则服务开发人员必须在两个系统之间为每个产品执行ETL，而不仅仅是盈利性服务。现在，由于我们没有一套服务来处理这个问题，生产支持会获得请求，然后必须更新与该给定产品相关的1+系统。
因此，如果服务适用于狭窄的片段，但基于例外的业务流程会破坏它，那是否意味着服务的边界不正确并且需要考虑业务流程的变化？
二，添加日期参数是否过多地扩展了服务的边界，或者是否应该除外，如果服务已经有参数，它也会有参数历史记录？此时，我们没有一个只存储参数的服务，因为没有人需要它。
如果在得到答案之前需要澄清，请告诉我。
答案 0 :(得分：0)
我认为这里的关键是：两个团队如果和ETL之间引入了多少痛苦？
并不是说我认为你过度分析了这一点，但如果可以的话，你可能会认为在服务合同中添加日期参数是不好的，但也不喜欢ETL的想法。
嗯，除了策略之外，我发现这些天我最重要的本能是更少关注技术问题，更多关注纯粹实用。
在一天结束时，ETL简单，可靠，并且相对无痛苦地实施，但它带有副作用。主要的一点是，您将把对服务的数据库模式的更改与外部方进行耦合，这将限制将来发展服务的选项。
另一方面，允许消费者需求决定服务的发展是容易和低摩擦的，但也是一条艰难的道路，因为你可能会以牺牲他人为代价来吸引那些消费者。
另一种可能性是允许额外的服务参数通过message传递给消费者，而不是通过相同的服务传递给消费者。这样您就可以保持服务边界的完整性，并使消费者能够保持本地所需的必要参数。
如果这不能直接解决您的问题，请道歉。