Clean Architecture中的“用例”是什么？

Question

我试图在我正在开发的应用程序中实现Clean Architecture结构，但我很难弄清楚到底是什么。

例如，如果我是对的，我的应用程序的实体是Employee、Department、EmployeeSkill。这些实体还包括所有的“验证”逻辑，以确保这些实体是有效的。

用例是我可以对这些实体执行的各种操作吗？

例如，关于Employee的用例

add-employee.js
remove-employee-by-id.js
update-employee-department.js
update-employee-phone-number.js
...and-more-employee-updates.js

这些都是实际的用例吗？

现在我不认为add和remove有太多要讨论的了，但是更新呢？他们应该是这样的granulated吗？

同样使用这样的体系结构，这不是意味着，如果我想同时更新员工部门和电话号码，我将不得不对数据库进行两个单独的调用，因为数据库适配器被注入到用例中，并且每个用例都从“查找”数据库中的实体开始？

Answer 1

现在暂缓考虑实体。通常，你试图根据你的世界心理模型来抽象代码，这并不像我们所相信的那样有帮助。

相反，将因为一个原因而一起更改的代码耦合到用例中。一个好的开始可能是GUI中的每个crud操作都有一个crud。新方法、新参数或新类等的内容不是CA模式的一部分，这是您在编写代码时面临的正常权衡的一部分。

我在你的例子中看不到任何实体。在我的代码库中，ContactCard (我在处理2021年的黄页类应用程序)和UserContext (安全)是唯一的实体，这两个东西到处都在使用。

其他东西只是数据持有者，而不是真正的实体。我有许多数据持有者的副本，所以没有耦合的东西保持不耦合。

您的存储库可能应该实现桥接模式。这意味着业务逻辑定义了一些存储库实现的桥梁。用例不知道数据库表，所以它没有任何粒度要求(如果它是在麦当劳点餐，它不会从烤架上说我想要xxx，从油炸机上我想要yyy)。

桥接定义中的用例要求非常苛刻。如此之多，以至于许多存储库最终都有api层来导入和管理桥的实现，然后它们适配内部逻辑。

这就是业务应用中的接口层与大多数B2C api之间的区别。用于用例的企业API正是用例所需的。

如果你已经被一个虚构的世界模型所约束，并决定在其中拆分repos，而不是按用例拆分它们，那么你最终会得到很差的对齐。在多个存储库中拥有相同的sql查询或其中的一部分不是问题。随着时间的推移，查询在很多时候看起来都不同，即使它们开始时非常相似。

我把你的例子称为UpdatePhoneNumberEverywhere的用例。然后UpdatePhoneNumberEverywhereRepository实现，可以做它想做的任何事情，这就是细节。用例并不关心。

我可能要做的另一个是UpdatePhoneNumber，用例接受一个策略。Strategy.CASCADE或Strategy.Leaf等

就你的表格设计而言，即使它是一个细节，联系人可能也应该被分解出来。

每个用例都不是从从数据库中找到一些东西开始的。命令和查询被传入或调用，用例做了一些有用的事情。

编写用例最实用的方法就是准确地实现您需要的业务需求，在用例中针对公共api编写所有测试。只需传入数据作为开始，字典通常就可以了。

实体通常是后来发现的，当你无法忍受有这么多版本的东西时，你只需要一些东西是稳定的，并且所有的东西都是一样的，你的最终用户也有同样的期望。然后，只要重构即可。