在领域驱动设计中，您如何考虑您的领域(命名空间)？
我一直在转向以下概念:
Project.Entity
Project.Entity.Abstracts
Project.Entity.Entities
Project.Entity.Extensions
Project.Entity.Immutables
Project.Entity.Interfaces
Project.Entity.Repositories
例如，我在 CMS 中有一个名为“Content”的实体。因此，我将创建一个名为 Project.Content 的项目，并将类分解为如下所示:
interface IContent
class Content : IContent
interface IContentRepository
class ContentRepository : IContentRepository
这个“内容”实体模型将有自己的命名空间。
但是，我发现它在具有十多个“实体”模型项目(尝试 18 个)的大型企业环境中不能很好地扩展。我最终得到了一个包含十几个项目的解决方案，其中一些只有 2 或 3 个类(即 UrlRewriter)。此外，我发现自己引用其他项目只是为了他们的接口(interface)。我觉得这污染了我的领域；虽然不是具体的引用，但有时很难避免循环引用。
所以，我有时会回到“层”的概念......
我想知道其他 DDD 专家如何分解企业级应用程序。请随时推荐书籍和文章。
并提前感谢!
最佳答案
一种想法是我做的是添加一些标识有界上下文的东西。
附言。为确保清楚原因，请检查有界上下文中的两个链接:
http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html , http://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx
关于refactoring - 在领域驱动设计中，您如何考虑您的领域(命名空间)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/619131/