WCF - 设计参数决策

Question

我正在为 FundManagement 设计一项服务。 FundManagement Service 有一个名为“UpdateFundApprovalDate(FundDTO fund)”的操作。此操作将使用fundingID 的批准日期更新资金表记录。该服务将由“FundManagementUI”客户端使用。

有一条业务规则，如果正在进行合同续订，则不应更新批准日期。

有单独的续订服务。 Renewal 服务使用 Renewal 表中的数据（其中包含 Funding ID）。 Renewal 表的结构是（RenewalID、FundingID、RenewalStartDate、Renewal CompletionDate、RenewalStatus）。有一个名为“public List GetInProgressRenewal(FundDTO fund)”的服务操作。

这里有一个重点。虽然这两种服务都使用相同的数据库，但“进行中”的续订应由续订服务决定。它可以基于更新记录的状态或完成日期。由续订服务决定“进行中”续订的业务逻辑。 FundManagement Service 声称对该逻辑没有所有权。

1. 解释上述行为的 SOA 原则/模式是什么？ （使用续订服务来确定“进行中”的续订，尽管续订服务可能会根据自己的利益改变逻辑。）。此类场景的指导方针是什么？

2. 您对任何涉及此类设计决策的文章有什么建议吗？

3. 在 FundManagement 服务中，谁应该负责验证返回的续订列表是否为 NULL？这种验证应该发生在服务操作方法代码内还是 FundBusinessLayer（服务调用者）内？

注意：这里的 SOA 将使用 WCF 实现，而业务类将是使用 C# 开发的 dll。

阅读：

1. SOA/WCF dissecting the system & service boundaries

Answer 1

财务信息的任何处理都将围绕一个关键方面进行 - 仔细管理状态。

尝试为您的合约系统创建一个状态模型，并仔细记录从给定状态可以达到哪些状态，以及为了从一种有效状态转移到另一种有效状态必须进行哪些处理。然后，确保在交易中发生从一个状态到另一个状态的任何移动，以便未能实现下一个状态将合约返回到其先前状态。

您可能会发现，如果您细化您的状态以反映当前的处理过程，这将使您更容易 - 即，而不是 REVIEWED、RENEWED、APPROVED、REJECTED、FUNDED，还有设置为指示合同处于不断变化的状态——即现在正在审查、正在资助等等。通过这种方式，系统可以识别当前正在积极处理的合同。如果环境在没有成功回滚的情况下突然崩溃，它还可以轻松识别发生了什么。

确保您只有一个更新合同状态的服务，并且该服务在更新期间锁定合同。所有其他进程都将使用此服务来执行所需的状态更改。

因此，在您的具体情况下，UpdateFundApprovalDate(FundDTO fund) 将仅在状态为 PENDING_FUNDING 的合同上运行，并且可能只是整个处理的一部分 - 无论如何，当运行 updateFundApprovalDate 的流程时(FundDTO fund) 完成时，如果成功，则合约状态将为 FUNDED - 或者如果尝试注资失败，则所有更改都将回滚，从而导致原始合约状态为 PENDING_FUNDING。如果系统崩溃，合同状态可能会处于当前处理状态，状态类似于 FUNDING。在你的状态模型中，FUNDING 本身不是一个有效的状态——它是一个临时状态。所有流程只会开始处理处于有效状态的合同，而不是临时状态。

对于可以在这种情况下使用的模式，请查看状态机模式。

Answer 2

在这种情况下，我不会使用续订服务中的现有服务，就像您说的那样，它们可以更改。

我遵循 SOA 中的服务应该具有业务意义的原则。

因此，我将创建一个新操作：IsContractRenewalInProgress。这消除了考虑谁应该负责验证返回的续订列表是否为 NULL 的需要。更重要的是，该列表为 NULL 意味着没有正在进行的合同更新。

然后，UpdateFundApprovalDate 将调用并检查 IsContractRenewalInProgress 的结果，然后再进行任何更改。

IsContractRenewalInProgress 应该在 Renewal Service 中，因为 Renewal Service 拥有数据和业务逻辑以了解何时进行合同续订。