与洋葱建筑的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是my Bounded Context A,但是 Bounded Context B,Bounded Context C等等也需要使用完全相同的Model A,您是否允许它们使用完全相同的模型,或者为每个模型创建一个新模型Bounded Context？

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

任何帮助都感激不尽.

Answer 1

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

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

   不同的项目/解决方案更多的是组织选择.如果单独的团队在BC上工作,它会使事情变得容易一些,而单独的二进制文件意味着BC可以更加独立地部署.

如果你有一个使用我的有界上下文A的模型A,但有界上下文B,有界上下文C等也需要使用完全相同的模型A,你是否允许它们使用完全相同的模型,或者你是否创建了每个有界上下文的新模型？

2. 这需要更多的域分析来讲述,但是有界上下文的整个要点是能够从完全不同的角度查看事物.在极少数情况下

   • 完全相同的实体用于3个不同的BC
   • 你不认为他们将来会以自己的方式发展
   • 该实体似乎并不属于特定的BC

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