清洁建筑 - 罗伯特马丁 - 用例粒度

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，那么它就是一个有效的用例，并且最好以反映业务逻辑的方式命名它。

如果一个交互可以准确反映您的业务逻辑，则可以调用其他交互。问自己以下问题：如果 UpdateAccountBalance 的要求发生变化，是否也会UpdateAllAccountBalances以完全相同的方式产生影响？如果答案是肯定的，那么实现此目的的最佳方法是进行UpdateAllAccountBalancescall UpdateAccountBalance，因为否则，您将需要在两个地方进行更改以保持它们的一致性。如果答案是否定的，那么您想要解耦这两个交互，这可以通过让它们调用共享函数来完成。