example -- This is bounded context,as a solution to your problem domain.
├── application -- This is use case,your user story will be reflected here.
├── domain -- This is domain,your business logic will be implemented here.
│   ├── model -- This is the business entity.
│   │   ├── feature1 
│   │   └── feature2
│   ├── service -- This is domain service.
│   └── repository -- This is repository interface.
└── infrastructure
    ├── remote -- Implementation of any call use case.
    │   ├── contorller
    │   └── listener
    └── repository -- Repository implementation.

关于您的问题，实体部分可以参考DDD的总体设计。
1..n个实体和0..n个值对象组合成一个聚合，最外面的实体是聚合根。
聚合之间的交互逻辑通过域服务实现。
每个聚合都是内聚的，不要让聚合相互依赖，否则会出现强耦合，责任不再单一，难以测试。
域不依赖于其他两个软件包。
应用程序依赖于域，但不依赖于基础结构。
基础设施。远程依赖于应用程序，这是用例入口。
基础结构。存储库实现域。存储库。
基础设施.远程和基础设施.存储库从不相互依赖。
欢迎指导和沟通，有问题可以回复我。
以上英语是谷歌翻译的，一些用词问题请谅解。

与MartinPeek所说的相反，NOWHERE在Clean Architecture一书中写道 “建议域模型是一个包”。popular clean architecture diagram绝不是应该如何实现应用程序目录结构的指南。实际上，Uncle Bob已经明确指出“Screaming”架构将使其应用用例从顶部可见。在其最后一章“缺失的一章”中作者是SimonBrown，他评估了不同的打包方式，并从按层打包如何违反Clean架构规则开始。
当您按层实施打包时，源目录将具有不同的子目录，例如domain/entities、use-cases、data-access-gateway/repositories、web-api、presenters、views等，这会凸显清洁体系结构，但不是您的系统的意图，即医疗保健管理应用程序，或购物车服务。当您尝试对单个功能进行单个更改时，您将不得不在4个不同的软件包中进行相应的更改。
如果你想真实地实现Clean架构，那么你不应该根据水平层来划分你的包，而是应该垂直地跨层划分它。（域实体和用例）在根目录本身中。每个包应该Map到你的业务逻辑中的一个域，这样所有因为相同原因而改变的用例和实体都被打包在一起，并且所有因不同原因而改变的用例和实体都被隔离。这样，你将得到一个如下的目录结构：database，api，employee，wages，taxes。甚至不给你任何提示，你就已经对这个应用程序可能是关于什么的有了大致的想法。
您也可以在根目录中将数据访问层、API和UI相关模块放在它们自己的独立包中，并让用例访问它们，或者您甚至可以将它们封装在“垂直切片”本身中，正如Uncle Bob所说：
如果您将系统中因不同原因而更改的元素解耦，则可以继续添加新用例，而不会干扰旧用例。如果您还将UI和数据库分组以支持这些用例，以便每个用例使用UI和数据库的不同方面，则添加新用例将不太可能影响旧用例。
但当然，这也有它的优点和缺点。
为了进一步阅读，我发现这个博客很有帮助，当我第一次开始：Explaining Clean Architecture
关于你的问题，
我可以在我的主特征中使用特征1和特征2的实体吗？
实体被允许相互对话，事实上它是任何业务逻辑的一部分，但是当我们从抽象到具体的层次越高，你应该保持事情越隔离。再次，当你做一个改变时，你不应该需要改变与那个改变无关的用例。所以我建议你创建一个单独的用例来访问两个实体。或者创建一个单独的实体，它是feature 1和feature 2实体的集合，并实现一个新特性来访问它，然后您可以让您的主特性使用这个新创建的用例。

更好的问题是，为什么要将域层与多个特性分离？在干净的体系结构中，域模型被建议为一个独立的包，它与其他包没有依赖关系。
因此，我会将域模型放入自己的包中，让不同的特性通过它们的用例访问它。
Clean architecture by Uncle Bob