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

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

• 你有一个模块/名称空间/包/目录，它不依赖于任何基础设施或技术（如REST，SQL，NOSQL，MONGO等），只有你的业务逻辑应该保留;这里有Aggregates，Value对象，Domain服务，Sagas等。每个Bounded上下文至少有一个;让我们将其命名为Domain层。它可能不依赖于其他域层。它应该是无副作用，易于检测的。
• 您可以在域层内部使用共享组件，但前提是它们是无状态和通用目的，如日期时间操作库，列表，堆栈等。
• 从远程模型转换为本地模型的反腐败层。最有可能的是它们依赖于多个Domain层。
• 其他演示，基础架构和技术特定的库和框架，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不应包含来自多个域/有界上下文的逻辑
• Feature1.ACL（反腐败层）可以依赖于基础设施（即，从数据库或缓存中存储/获取），但不应包含业务逻辑，仅包含映射逻辑，从远程对象/概念到本地对象/概念。