如何在.Net中正确实现共享内核（DDD）

我有一个我正在重新设计的遗留应用程序，因为它在这一点上我们称之为“泥球”，根本没有分层或SOC。团队习惯于模块化工作，这意味着有一个团队负责“培训”、“工作机会”，一个团队负责管理“职责规划（军事）”模块。我们有一个网站向我们的客户公开这些领域，作为一个服务门户，一个数据库和一些我们服务的外部应用程序

我在重新设计大多数层方面做得很好，除了如何正确划分域（我应该在这里提到，我们正在使用.NET4.0）。我最初的想法是，由于它们的工作方式，这些都是有限的上下文，它们似乎真的有不同的用户集，但我相信现在的现实是，使用这个网站的人可能而且确实同时使用了许多区域。当然，有些团体只使用一种服务，但很多团体使用多种服务。该网站的目标是对“会员”进行一站式管理。在模块之间，我们有模块特有的类，然后我们有一些共享类，例如，所有模块都知道并使用成员的概念。会员实际上是一个核心概念，网站通过一次跟踪所有这些领域的会员信息来增加价值。基本上就是这样，系统中几个密切相关但独立的区域和一个共享区域。我希望这足够清楚地回答我的问题

我认为，对于通用实体和共享域接口（如通用存储库接口），即使它们不是有界上下文，我仍然会有一个共享内核。将所有公共代码（通用存储库、核心域模型、共享内核等）放在同一个名称空间或名称空间层次结构中是否明智？我是否应该在它自己的程序集中隔离此名称空间？同样地，我会将每个区域（“培训”、“机会”…）分解成它们自己的程序集，还是最好将它们都放在一个程序集中，并按名称空间进行逻辑分区。一方面，可以更容易地看到模块的物理分区，但我担心两个模块需要一起工作来解决问题的情况。他们将如何通信并保持事物的非循环性（我猜是通过应用层中的服务）

so（选项摘要）：

域模型（dll） --Domain.Model.Core --内核（共享实体和核心域模型） --存储框架 --等等。。。 --域模型训练 --Domain.Model.Opportunities

或

Domain.Model.Core

Domain.Model.Training（dll）

Domain.Model.Opportunities（dll） （培训和机会如何协同工作？）

---

非常感谢您的时间，

如果是物理布局，我会将所有内容（整个域模型）放在一个组件中。使用单独的程序集不会给您带来任何好处，同时会使事情复杂化并增加编译时间

另一方面，如果存在某些开发人员使用不适当类（属于其他模块/上下文的类）的风险，则明智的做法是将逻辑拆分为公共程序集（核心域、共享内核）和特定于每个模块/上下文的程序集

在逻辑布局（名称空间）的情况下，我将为每个部分提供一个单独的名称空间（例如DomainModel.Core、DomainModel.Training）。有时，明智的做法是更进一步，将每个聚合放入其自己的命名空间中。它可以防止意外跨越聚合边界，因为它需要单独的“使用”指令

希望这是有道理的