我正在为FundManagement设计服务。 FundManagement Service有一个名为“UpdateFundApprovalDate（FundDTO fund）”的操作。此操作将使用fundingID的批准日期更新资金表记录。该服务将由“FundManagementUI”客户使用。
有一项业务规则，如果合同续订正在进行，则不应更新批准日期。
有一个单独的续订服务。续订服务使用续订表中的数据（其中包含资金ID）。更新表的结构是（RenewalID，FundingID，RenewalStartDate，Renewal CompletionDate，RenewalStatus）。有一个名为“public List GetInProgressRenewal（FundDTO fund）”的服务操作。
这里有一点重要。虽然两个服务都使用相同的数据库，但“续进”续订应由续订服务决定。它可以基于续订记录的状态或完成日期。由续订服务决定“进行中”续订的业务逻辑。 FundManagement Service声称没有对该逻辑的所有权。
解释上述行为的SOA原则/模式是什么？ （使用续订服务确定“进行中”续订，但续订服务可能会根据自身利益更改逻辑。）。有关此类情景的指导原则是什么？
对于任何涉及此类设计决定的文章，您有什么建议吗？
在FundManagement服务中，谁应该负责来验证返回的续订列表是否为NULL？这种验证应该在服务操作方法代码内部还是在FundBusinessLayer内部（服务人员调用）中进行？
注意：这里的SOA将使用WCF实现，业务classess将是使用C＃开发的dll。
读：
答案 0 :(得分：4)
在这种情况下，我不会使用续订服务中的现有服务，就像您说他们可以更改一样。
我遵循的原则是SOA服务应该具有商业意义。
因此我会创建一个新操作： IsContractRenewalInProgress 。这样就无需考虑谁应该负责验证返回的续订列表是否为NULL。更重要的是，列表为NULL意味着没有正在进行的合同续订。
UpdateFundApprovalDate 会在进行任何更改之前调用并检查 IsContractRenewalInProgress 的结果。
IsContractRenewalInProgress应该在续订服务中，因为它是拥有数据和业务逻辑的续订服务，以了解合同续订的进行时间。
答案 1 :(得分：1)
财务信息的任何处理都围绕着一个关键方面 - 精心管理地位。
尝试为合同系统创建状态模型，并仔细记录从给定状态可以到达的状态，以及为了从一个有效状态移动到另一个有效状态必须进行的处理。然后，确保在事务中发生从一个状态到另一个状态的任何移动，使得未能实现下一状态将合同返回到其先前状态。
您可能会发现，如果您将状态粒化以反映当前的处理方式（即，而不是审核，更新，批准，拒绝，资金来源），也会使您更容易，这些州也会设置为表明合同处于合同状态流量状态 - 即它正在进行审查，现在正在获得资金支持等。通过这种方式，系统可以识别正在积极处理的合同。如果环境在没有成功回滚的情况下突然崩溃，它还可以很容易地识别出发生了什么。
确保您只有一个服务可以更新合同的状态，并且此服务会在更新期间锁定合同。所有其他进程都将使用此服务来执行所需的状态更改。
因此，在您的特定情况下，UpdateFundApprovalDate（FundDTO基金）只会在状态为PENDING_FUNDING的合同上运行，并且可能只是整个处理的一部分 - 无论如何，当运行updateFundApprovalDate的过程时（FundDTO基金）完成后，如果成功，合同状态将为FUNDED - 或者如果资金尝试失败，则所有更改都将被回滚，从而导致PENDING_FUNDING的原始合同状态。如果系统崩溃，合同状态可能会保留在当前处理状态，状态类似于资金。资金本身在你的州模式中不是一个有效的状态 - 它是一个临时状态。所有流程只会开始处理有效状态的合同，而不是临时状态。
对于可以在这种情况下使用的模式，请查看状态机模式。