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

Question

我有一个遗留的应用程序我正在重新设计,因为这就是我们所谓的"混乱之球",没有任何分层或SOC.该团队习惯于模块化工作,这意味着有一个团队致力于"培训","工作机会",一个工作在管理"职责规划(军事)"的模块.我们有一个网站向我们的客户公开这些区域作为服务门户,一个数据库和我们服务的一些外部应用程序.

我正在重新设计大多数层,除了如何正确地分区域(我应该在这一点上提到我们正在使用.Net 4.0).我最初的想法是,这些都是有限的背景,因为他们的工作方式,他们似乎真的有不同的用户组,但我相信现在现实是使用这个网站的人可能并且确实同时使用许多区域.当然,有些团体只使用一项服务,但很多人使用多项服务.该网站的目标是"成员"的一站式管理.在模块之间,我们有模块特有的类,然后我们有一些共享类,例如,成员的概念是已知的并且被所有模块使用.会员实际上是一个核心概念,该网站通过在所有这些领域同时跟踪会员的信息来增加价值.基本上就是它,系统中的一些密切相关但分开的区域和共享区域.我希望这很清楚,可以回答我的问题.

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

所以(选项摘要):

Domain.Model(dll) - Domain.Model.Core - 内核(共享实体和核心域模型) - RepositoryFramework - etc ... - Domain.Model.Training - Domain.Model.Opportunities ...

要么

Domain.Model.Core

Domain.Model.Training(dll)

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

非常感谢您的宝贵时间,

Answer 1

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

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

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

希望这是有道理的。