.net - 如何在 .Net 中正确实现共享内核 (DDD)

Question

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

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

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

所以(选项摘要):

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

或

域.模型.Core

域.模型.训练(dll)

域.模型.机会 (dll)(培训和机会如何协同工作？)

非常感谢您抽出宝贵的时间，

Answer 1

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

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

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

希望这是有道理的。