DDD驱动解决方案结构

Question

我正在创建一个基于DDD原则的项目。当我在网上阅读资源时，我想出了以下几点，这有意义吗？特别是，以下部分：

• 具有在有界上下文之间共享的Shared.Core项目
• 对每个有界上下文具有单独的.Data项目
• Rest.API依赖于Shared.Core和FeatureX.Core项目。

下表显示了我创建的项目及其依赖关系，->表示“依赖于”。

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

Answer 1

您可以任意命名文件夹，但建议如下：

• 您有一个模块/命名空间/package/目录，它不依赖于任何基础设施或技术(如REST、SQL、NOSQL、MONGO等)，而这些基础设施或技术只有您的业务逻辑才能保留；这里有一个Aggregates、Value对象、Domain services、Sagas等。每个有界上下文至少有一个；让我们将其命名为域层。它可能不依赖于其他域层。它应该是副作用免费，容易测试。
• 您可以在域层共享组件中使用，但前提是它们是无状态的和通用的，比如日期时间操作库、列表、堆栈等等。
• 从远程模型转换到本地模型的反腐败层。最有可能的是，它们依赖于多个域层。
• 其他表示、基础设施和技术特定的库和框架、IO适配器和端口应该清楚地与其他层分离。可能依赖于域层。

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

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

附有以下评论：

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