我正试图在我正在开发的应用程序中实现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吗？
同样，有了这样的体系结构，这并不意味着，如果我想同时更新员工部门和电话号码，我将不得不对数据库进行两次单独的调用，因为数据库适配器正在注入用例中，每个用例都以"开头；发现"；数据库中的实体？
暂时推迟对实体的思考。通常，你会被困在试图根据你的世界心理模型抽象代码的过程中，这并不像我们所相信的那样有帮助。
相反，将出于一个原因而一起更改的代码耦合到用例中。GUI中的每个crud操作都可以有一个良好的开始。新方法、新参数或新类等所要做的不是CA模式的一部分，这是编写代码时所面临的正常权衡的一部分。
从你的例子中我看不出任何实体。在我的代码库中，ContactCard(我在2021年的一款应用程序中使用黄页(和UserContext(安全(是唯一的实体，这两个东西到处都在使用。
其他东西只是数据持有者，而不是真正的实体。我有许多数据持有者的副本，所以没有耦合的东西保持不耦合。
您的存储库可能应该实现桥接模式。这意味着业务逻辑定义了一个桥，由一些存储库实现。这个用例不知道数据库表，所以它没有任何细粒度的要求(如果它是在麦当劳点餐，它不会说从烤架上我想要xxx，从油炸锅上我想要yyy(。
用例在网桥定义中要求很高。如此之多，以至于许多存储库最终都拥有导入和管理桥接实现的api层，然后它们与内部逻辑进行适配。
这就是商业应用程序中的api层和大多数B2C api之间的区别。用例的企业API正是用例所需要的。
如果你已经被一个虚构的世界模型所约束，并决定在这个模型中拆分回购，而不是按照每个用例进行拆分，那么你最终会出现不协调的情况。在多个存储库中拥有相同的sql查询或其中的一部分不是问题。随着时间的推移，查询在很多时候看起来都不一样，即使它们一开始非常相似。
我将调用UpdatePhoneNumberEverywhere的示例用例。然后UpdatePhoneNumberEverywhereRepository实现，可以随心所欲，这是一个细节。用例并不关心。
我可能会做的另一个是UpdatePhoneNumber，并且用例接受一个策略。Strategy.CASCADE或Strategy.Leaf等
就你的桌子设计而言，尽管这是一个细节，但"联系人"可能值得打破。
并非每个用例都是从数据库中查找内容开始的。命令和查询是传入的，或者通过您调用它，用例会做一些有用的事情。
编写用例最实用的方法是准确地实现业务需求所需的内容，在用例中针对公共api编写所有测试。只要先传入数据，字典通常就可以了。
实体通常是在以后发现的，当你无法忍受某个东西有这么多版本时，你只需要该东西稳定且始终相同，而你的最终用户也期望如此。然后，只需重构即可。