访问和使用 Clean Architecture 中其他功能的实体

Question

我已经为应用程序的每个部分创建了功能包，我的项目结构如下所示：

\n

app\n    core\n    features\n        main\n            domain\n            data\n            ui\n        feature1\n            domain\n                entities\n                    entity1\n                    entity2\n                \xe2\x80\xa6\n            data\n            ui\n        feature2\n            domain\n                entities\n                    entity1\n                    entity2\n                \xe2\x80\xa6\n            data\n            ui\n

\n

我的问题是我可以在我的主要功能中使用feature1和feature2的实体吗？如果这不是正确的方法，有没有更好的解决方案？\n谢谢大家。

\n

Answer 1

与MartinPeek所说的相反， 《清洁架构》一书中没有任何地方写到“建议将领域模型作为一个包”。流行的简洁架构图绝不是关于如何实现应用程序目录结构的指南。事实上，Uncle Bob 已经明确表示，“尖叫”架构将使其应用程序用例从顶部可见。在 Simon Brown 贡献的最后一章“缺失的章节”中，他评估了不同的打包方式，并从分层打包如何违反 Clean 架构规则开始。

当您实现分层打包时，您的源目录将具有不同的子目录，例如domain/ entities、、/ 、、、use-cases等，这呼唤着干净的架构，但不是您的系统的意图，即医疗保健管理应用程序或购物车服务。当您尝试对单个功能进行单个更改时，您将不得不在 4 个不同的包中进行更改。data-access-gatewayrepositoriesweb-apipresentersviews

如果你想真正实现 Clean 架构，那么你应该垂直地跨层划分你的包，而不是水平分层。您应该在根目录本身中有应用程序层（域实体和用例）。每个包应该映射到业务逻辑中的一个域，这样所有因相同原因而更改的用例和实体都被打包在一起，并且所有因不同原因而更改的用例和实体都被隔离。这样，您最终将得到如下目录结构：database, api, employee, wages, taxes。甚至无需给您任何提示，您就可以大致了解此应用程序的用途。

您也可以将数据访问层、API 和 UI 相关模块放在根目录内各自单独的包中，并让用例访问它们，或者您甚至可以将它们封装在“垂直切片”本身内，就像 Uncle 一样鲍勃说：

如果您将因不同原因而发生变化的系统元素解耦，那么您可以继续添加新用例，而不会干扰旧用例。如果您还对 UI 和数据库进行分组以支持这些用例，以便每个用例使用 UI 和数据库的不同方面，那么添加新用例将不太可能影响旧用例。

但当然，这有其自身的优点和缺点。

为了进一步阅读，我发现这个博客在我刚开始时非常有帮助：解释干净的架构

回答你的问题，

我可以在我的主要功能中使用 feature1 和 feature2 的实体吗？

实体之间可以相互通信，事实上它是任何业务逻辑的一部分，但是当我们从抽象到具体的更高层时，您应该让事物更加隔离。同样，当您进行更改时，您不需要更改与该更改无关的用例。因此，我建议您创建一个单独的用例来访问这两个实体，或者创建一个单独的实体，该实体是 feature1 和 feature2 实体的聚合，并实现一个新功能来访问它。然后您可以让您的主要功能使用这个新创建的用例。

Answer 2

更好的问题是，为什么要将领域层分成几个功能？在干净的架构中，建议域模型本身就是一个包，不依赖于其他包。

因此，我会将域模型放入自己的包中，并让不同的功能通过其用例访问它。

鲍勃叔叔的干净建筑