DDD 驱动的解决方案结构

Question

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

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

下面table是我创建的项目及其依赖，->表示'depends on'。

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

Answer 1

您可以随意命名文件夹，但建议：

您的 module/namespace/package/directory 不依赖于任何基础架构或技术（如 REST、SQL、NOSQL、MONGO 等) 只有您的业务逻辑应该保留的地方；这里有聚合、值对象、领域服务、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.Domain 不应包含来自多个 Domain/Bounded 上下文的逻辑
Feature1.ACL（反腐败层）可以依赖于基础设施（即从数据库或缓存到 store/fetch）但不应该包含业务逻辑，只有映射逻辑，从远程 objects/concepts 到本地 objects/concepts.

DDD 驱动的解决方案结构

DDD driven solution structure

dependencies

domain-driven-design

project

solution