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等(，只有你的业务逻辑应该保留;这里有聚合，值对象，域服务，Sagas等。每个界定上下文至少一个;我们将其命名为域层。它可能不依赖于其他域层。它应该是无副作用的，易于测试。

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

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

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

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

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

有以下评论：

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