洋葱架构的 DDD 限界上下文

Question

我有以下Onion Architecture 框架。

• Domain
  • Entities - 对于我的域实体
  • Interfaces - 用于我的域接口
  • Services - 用于我的域服务
• Infrastructure
  • Data - 用于Fluent NHibernate 持久性
  • Interfaces - 用于基础设施接口
  • Logging - 只是一个日志接口，以防我想将我的日志库切换到其他东西。
  • Dependency Resolution - 我的大部分IoC 注册都在这里。
• Services
  • Interfaces - 应用服务接口在这里，它们将在UI 项目中实现。
• Tests
  • Infrastructure Tests - 用于测试基础设施服务等。
  • Domain Tests - 用于测试领域模型和服务
• Web
  • UI - 我在其中实现应用程序服务、用户界面等的用户界面项目...

使用Domain Driven Development 可以识别Bounded Contexts。互联网上的大多数文献都指出，每个Bounded Context 都需要抽象到自己的项目或命名空间中。

1. 我的方法是否不正确，因为我的所有Domain Models 都在一个项目中，而我所有的Domain Services 都在另一个项目中？在不同的命名空间或项目中没有不同的限界上下文真的很重要吗？
2. 如果你有一个Model A 使用我的Bounded Context A，但Bounded Context B、Bounded Context C 等也需要使用完全相同的Model A，你是否允许他们使用完全相同的模型，还是为每个Bounded Context 创建一个新模型？

如果这个问题是一个愚蠢的问题，我是 DDD 的新手，很抱歉。如果我提出一个问题并得到一个很好的解释作为答案，我会发现自己能更好地理解一些事情。

任何帮助将不胜感激。

Answer 1

我的方法是否不正确，因为我的所有领域模型都在一个项目中，而我的所有领域服务都在另一个项目中？在不同的命名空间或项目中没有不同的限界上下文真的很重要吗？

1. 不同的命名空间是一个概念和一个实用的解决方案，否则当两个相邻的概念在不同的子域中使用相同的名称时，您可能会发生实体名称冲突。

   除此之外，不同的项目/解决方案更多是一种组织选择。如果单独的团队在 BC 上工作，事情会变得更容易一些，并且单独的二进制文件意味着 BC 可以更独立地部署。

如果您有一个模型 A 使用我的限界上下文 A，但限界上下文 B、限界上下文 C 等也需要使用完全相同的模型 A，您是否允许他们使用完全相同的模型，或者执行您为每个有界上下文创建一个新模型？

1. 这需要更多的领域分析才能说明，但限界上下文的全部意义在于能够从完全不同的角度看待事物。在极少数情况下

   • 完全相同的实体用于 3 个不同的 BC
   • 您不会看到他们在未来以自己的方式发展
   • 该实体似乎并不自然地属于给定的 BC

那么您可能想要使用共享内核模式。否则，只需复制每个 BC 中的实体，让它们过自己的生活，或者找到实体的真实 BC 并从其他 BC 链接到它的 ID。