访问和使用 Clean Architecture 中其他特性的实体

Question

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

app
    core
    features
        main
            domain
            data
            ui
        feature1
            domain
                entities
                    entity1
                    entity2
                …
            data
            ui
        feature2
            domain
                entities
                    entity1
                    entity2
                …
            data
            ui

我的问题是，我可以在我的主要功能？如果这不是正确的方法，是否有更好的解决方案？谢谢大家

Answer 1

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

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

Clean architecture by Uncle Bob

Answer 2

与 MartinPeek says, NOWHERE in the Clean Architecture book is it written that "the domain model is suggested to be one package". The popular clean architecture diagram 不同的是，它绝不是关于如何实现应用程序目录结构的指南。事实上，Uncle Bob 已经明确表示 'Screaming' 架构的应用程序用例从顶部可见。在由 Simon Brown 贡献的名为“The Missing Chapter”的最后一章中，他评估了不同的打包方式，并从逐层打包如何违反 Clean 架构规则开始。

当你实现分层打包时你的源码目录会有不同的子目录如domain/entities, use-cases, data-access-gateway/repositories, web-api、presenters、views 等尖叫 Clean Architecture，但不是您系统的意图，即 Healthcare Management应用程序，或购物车服务。当您尝试对单个功能进行单一更改时，您将不得不在 4 个不同的包中进行更改。

如果你想真正实现Clean architecture，那么与其按水平层划分你的包，不如垂直地跨层划分。您应该在根目录本身中拥有应用程序层（域实体和用例）。每个包都应映射到您的业务逻辑中的一个域，这样所有因相同原因发生变化的用例和实体都打包在一起，而所有因不同原因发生变化的用例和实体则被隔离。这样，您将得到如下目录结构：database、api、employee、wages、taxes。甚至无需给您任何提示，您就对该应用程序的内容有了大致的了解。

您也可以在根目录中将数据访问层、API 和 UI 相关模块放在它们自己单独的包中，并让用例访问它们，或者您甚至可以将它们封装在“垂直切片”本身中，正如 Bob 大叔所说：

If you decouple the elements of the system that change for different reasons, then you can continue to add new use cases without interfering with old ones. If you also group the UI and database in support of those use cases, so that each use case uses a different aspect of the UI and database, then adding new use cases will be unlikely to affect older ones.

当然，这有利也有弊。

为了进一步阅读，我发现这个博客在我刚开始时很有帮助：Explaining Clean Architecture

回答你的问题，

can I use entities of feature1 and feature2 in my main feature?

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

访问和使用 Clean Architecture 中其他特性的实体

Accessing and Using entities of other features in Clean Architecture

architecture

entity

flutter

clean-architecture