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

Question

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

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

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

so（选项摘要）：

Domain.Model (dll) -- 领域.模型.核心 -- 内核（共享实体和核心域模型） -- 存储库框架 - 等等... -- 领域.模型.训练 -- 领域.模型.机会 ...

或

Domain.Model.Core

Domain.Model.Training (dll)

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

非常感谢您的宝贵时间，

Answer 1

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

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

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

希望这是有道理的。