oop - 清洁架构 - Robert Martin - 用例粒度

Question

我正在考虑实现 Robert Martin 的 Clean Architecture在一个项目中，我试图找出如何处理非平凡用例。

我发现很难将架构扩展到复杂/组合的用例，尤其是参与者是系统而不是用户的用例，例如在执行某种批处理的系统中。

出于说明目的，让我们假设一个用例，如“系统更新所有帐户余额”，用伪代码实现，如

class UpdateAllAccountBalancesInteraction {
    function Execute() {
        Get a list of all accounts
        For each account
            Get a list of all new transactions for account
            For each transaction
                Perform some specific calculation on the transaction
            Update account balance
    }
}

此外，“获取所有账户的列表”、“获取账户的所有新交易的列表”、“对交易进行一些特定计算”、“更新账户余额”都是它们自己的有效用例，每个它们已经在它自己的交互类中实现了。

出现了几个问题:

用例“系统更新所有帐户余额”是否有效
用例还是应该将其分解为较小的用例(尽管
从商业角度来看，这似乎是有道理的，这是一个
合法的业务场景)？

是 UpdateAllAccountBalancesInteraction
合法的互动？

交互是否允许/应该协调其他交互？

是编排其他代码的代码吗
互动真的属于其他地方吗？

是否可以拥有
UpdateAllAccountBalancesInteraction 作为一个交互，但是有它
调用其他交互者共享的函数而不是充当
其他交互者的协调者？

Answer 1

显然，您有一个新的高级交互，它与低级交互共享一些(或许多)通用功能。还行吧。

如果业务需要一个名为 UpdateAllAccountBalances 的用例，那么它是一个有效的用例，并且以反射(reflect)业务逻辑的方式命名它是很好的。

没关系。对于一个交互调用其他交互，如果这准确反射(reflect)了您的业务逻辑。问问自己以下问题:如果 UpdateAccountBalance 的要求发生变化，这是否也会影响 UpdateAllAccountBalances以完全相同的方式？如果答案是肯定的，那么实现这一目标的最佳方法是拥有 UpdateAllAccountBalances调用 UpdateAccountBalance ，因为否则，您需要在两个地方进行更改以保持一致。如果答案是否定的，那么您希望将两个交互解耦，这可以通过让它们调用共享函数来完成。