我有一个遗留的应用程序我正在重新设计，因为它就是我们所说的“混乱球”，没有分层或SOC。团队习惯于模块化工作，这意味着有一个团队致力于“培训”，“工作机会”，一个工作在管理“职责规划（军事）”的模块。我们有一个网站向我们的客户公开这些区域作为服务门户，一个数据库和我们服务的一些外部应用程序。
我很好地重新设计了大部分图层，除了如何正确地对域进行分区（此时我应该提到我们正在使用.Net 4.0）。我最初的想法是，这些都是有限的背景，因为他们的工作方式，他们似乎有不同的用户组，但我相信现在的现实是使用这个网站的人可能并且确实一次使用许多区域。当然，有些团体只使用一项服务，但很多人使用多项服务。该网站的目标是“成员”的一站式管理。在模块之间，我们有模块特有的类，然后我们有一些共享类，例如，成员的概念是已知的并且被所有模块使用。会员实际上是一个核心概念，该网站通过在所有这些领域同时跟踪会员的信息来增加价值。这基本上就是它，系统中的一些密切相关但又分开的区域和共享区域。我希望这很清楚，可以回答我的问题。
我在想，对于公共实体和共享域接口（如通用存储库接口），我仍然会有共享内核，即使这些内核不是有界上下文。将所有公共代码（通用存储库，核心域模型，共享内核等）放入相同的命名空间或命名空间层次结构中是否明智？我应该在其自己的程序集中隔离此命名空间吗？同样，我是否会将每个区域（“训练”，“机会”......）分解为自己的程序集，或者将它们全部放在一个程序集中并按命名空间对它们进行逻辑分区更好。一方面，看到模块物理分区更容易一些，但我担心两个模块需要协同解决问题的情况。他们将如何沟通并保持非循环（通过我猜测的应用层中的服务）。
所以（选项摘要）：
Domain.Model（dll） - Domain.Model.Core - 内核（共享实体和核心域模型） - RepositoryFramework - 等...... - Domain.Model.Training - Domain.Model.Opportunities ...
或
Domain.Model.Core
Domain.Model.Training（dll）
Domain.Model.Opportunities（dll） （培训和机会如何协同工作？）
非常感谢你的时间，
答案 0 :(得分：3)
在物理布局的情况下，我会将所有内容（整个域模型）放在一个程序集中。使用单独的程序集不会给您带来任何好处，但会使事情变得复杂并增加编译时间。
另一方面，如果某些开发人员存在使用不合适的类（属于其他模块/上下文的那些）的风险，将逻辑拆分为公共程序集（核心域，共享内核）可能是明智的。特定于每个模块/上下文的程序集。
在逻辑布局（命名空间）的情况下，我会给每个部分一个单独的命名空间（例如DomainModel.Core，DomainModel.Training）。有时候更进一步将每个Aggregate放入自己的命名空间是明智的。它可以防止意外穿越聚合边界，因为它需要一个单独的“使用”指令。
希望这是有道理的。