在领域驱动设计中，您如何考虑您的领域（命名空间）？答案

【问题标题】：How do YOU factor your Domain (namespaces), in Domain Driven Design?在领域驱动设计中，您如何考虑您的领域（命名空间）？
【发布时间】：2023-03-29 15:28:01
【问题描述】：

在领域驱动设计中，您如何考虑您的领域（命名空间）？

我一直在转向以下概念：

Project.Entity
  Project.Entity.Abstracts
  Project.Entity.Entities
  Project.Entity.Extensions
  Project.Entity.Immutables
  Project.Entity.Interfaces
  Project.Entity.Repositories

例如，我在 CMS 中有一个名为“内容”的实体。因此，我将创建一个名为 Project.Content 的项目，并将类分解为如下所示：

interface IContent
class Content : IContent

interface IContentRepository
class ContentRepository : IContentRepository

这个“内容”实体模型会有自己的命名空间。

但是，我发现它在具有十多个“实体”模型项目（尝试 18 个）的大型企业环境中无法很好地扩展。我最终得到了一个包含十几个项目的解决方案，其中一些只有 2 或 3 个类（即 UrlRewriter）。此外，我发现自己引用其他项目只是为了他们的接口。我觉得这污染了我的领域；虽然不是具体的引用，但有时很难避免循环引用。

所以，我有时会回到“层”概念...

我想知道其他 DDD 专家如何分解企业级应用程序。请随时推荐书籍和文章。

提前致谢！

【问题讨论】：

标签： refactoring domain-driven-design

【解决方案1】：

我的想法是添加一些标识有界上下文的内容。

附言。为确保清楚原因，请检查有界上下文中的两个链接： http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html, http://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx

【讨论】：

更正链接：devlicio.us/blogs/casey/archive/2009/02/11/…

【解决方案2】：

我与您类似地发现，管理大量项目变得很痛苦。我更喜欢

Project.Domain
Project.DataAccess
Project.Presentation (presenters and such) 
Project.Gui (in case of a winforms app)

设置。

从某种意义上说，当事情变得糟糕时，让事情变得简单会大有帮助。

问题是当你创建另一个项目时你会得到什么？（这很容易做到，几乎很容易）

您是否愿意独立使用该项目？您最终可能会得到如此耦合的 .dll，如果没有完全相同的版本等，您甚至无法部署它们。在这种情况下，没有理由将其拆分并弄乱您的 IDE）

如果需要，您可以随时将内容转移到新项目中，这有点痛苦，但到那时，您将有充分的理由这样做，而不仅仅是感觉这样做的方式。

【讨论】：

我喜欢您的想法“您是否愿意独立使用该项目？”这是核心的架构设计思想；而且，它可能正是我想要的。让我在投票之前查看其他人的链接。谢谢！
不幸的是，我一直在做太多的项目，我变得如此凌乱......

【解决方案3】：

我使用关注.NET guidelines。我发现它们非常直观，它们允许你设置命名空间，这样你就不需要导入任何你不需要的东西。

我永远不会对功能级别强加严格的命名约定。每个不同项目的设计都应该指导这一点。

【讨论】：