我有以下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都需要被抽象到自己的项目或命名空间中。
Domain Models而在另一个项目中拥有所有Domain Services？在不同的命名空间或项目中没有不同的有界上下文真的很重要吗？Model A使用Bounded Context A，Bounded Context B，Bounded Context C等也需要使用完全相同的Model A，请执行你允许他们使用那个完全相同的模型，还是为每个Bounded Context创建一个新模型？ 我是DDD的新手，很抱歉，这个问题是个愚蠢的问题。如果我提出问题并得到一个好的解释作为答案，我发现自己更好地理解了一些东西。
非常感谢任何帮助。
答案 0 :(得分：6)
我的方法是不正确的，因为我在一个项目中拥有所有的域模型，而在另一个项目中拥有所有的域服务？在不同的名称空间或项目中没有不同的有界上下文真的很重要吗？
不同的命名空间是一个概念性的和实用的解决方案，因为否则当两个相邻的概念在不同的子域中使用相同的名称时，您可能会发生实体名称冲突。
不同的项目/解决方案更多的是组织选择。如果不同的团队在卑诗省工作，这会让事情变得容易一些，而单独的二进制文件意味着BC可以更加独立地部署。
如果你有一个使用我的有界上下文A的模型A，但是有界上下文B，有界上下文C等也需要使用完全相同的模型A，你是否允许他们使用那个完全相同的模型，或者做你为每个有界上下文创建一个新模型？
这需要更多的域分析才能说明，但是有界上下文的整个要点是能够从完全不同的角度查看事物。 <极少数情况下
然后您可能想要使用共享内核模式。否则，只需复制每个BC中的实体，让它们过自己的生活，或找到实体的真实BC，并链接到其他BC的ID。