Dependencies DDD驱动的解决方案结构

我正在创建一个基于DDD原则的项目。我在阅读互联网上的资源时得出以下结论，这有意义吗？特别是以下部件：

• 具有

  Shared.Core

  项目，该项目在有界上下文之间共享
• 为每个有界上下文提供单独的

  .Data

  项目
• 拥有依赖于

  Shared.Core

  和

  FeatureX.Core

  项目的

  Rest.API

下表显示了我创建的项目及其依赖关系，

->

表示“依赖”

Rest.API -> Feature1.Core -> Feature1.Data
                          -> Shared.Core
         -> Feature2.Core -> Feature2.Data
                          -> Shared.Core
         -> Shared.Core

---

您可以根据需要为文件夹命名，但建议：

• 您有一个模块/名称空间/包/目录，该模块/名称空间/包/目录不依赖于任何基础设施或技术（如REST、SQL、NOSQL、MONGO等），其中只有您的业务逻辑；这里有聚合、价值对象、域服务、传奇等，每个有界上下文至少有一个；让我们把它命名为域层。它可能不依赖于其他域层。它应该没有副作用，易于测试

• 您可以在域层内使用共享组件，但仅当它们是无状态的和通用的，如日期时间操纵库、列表、堆栈等时才可以使用

• 从远程模型转换为本地模型的反损坏层。它们很可能依赖于多个域层

• 其他表示、基础架构和特定于技术的库和框架、IO适配器和端口应与其他层明确分开。可能取决于域层

因此，要映射到您已经拥有：

Rest.API -> Feature1.Domain -> Shared.Lib
         -> Feature1.Infrastructure
         -> Feature1.ACL -> Feature1.Infrastructure
         -> Feature2.Domain -> Shared.Lib
         -> Feature2.Infrastructure
         -> Shared.Lib

有以下评论：

• Lib应该只包含技术无关、无副作用的库、语言构造、实用程序函数等
• 功能1.域不应包含来自多个域/有界上下文的逻辑
• Feature1.ACL（反损坏层）可能取决于基础结构（即从数据库或缓存存储/获取），但不应包含业务逻辑，只应包含从远程对象/概念到本地对象/概念的映射逻辑

---

非常感谢，但这与我所拥有的有什么关系呢？域层不应该依赖于基础设施，所以我应该扭转

*。数据
，反腐败层应该在
Rest。API
我假设，一般共享的东西进入
共享。核心
@eddyP23首先，
数据
很难看，它应该是
Domain
@eddyP23，什么是
.Core
？所以在我的例子中，我认为
.Core
就是你所说的
Domain
，而
就是基础设施bit@eddyP23是的，每一层都可以依赖于域
。Data
-surfix是基础设施实现的常用工具（即数据库），不用于逻辑