在域驱动设计中,您如何考虑域(名称空间)?

时间:2009-03-06 14:55:01

标签: refactoring domain-driven-design

您如何在域驱动设计中考虑您的域名(命名空间)?

我一直在转向以下概念:

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)。此外,我发现自己只是为了他们的接口引用其他项目。我觉得这是在破坏我的领域;虽然不是具体的参考文献,但有时很难避免使用循环引用。

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

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

提前谢谢!

3 个答案:

答案 0 :(得分:1)

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

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

答案 1 :(得分:1)

有人认为我做的是添加一些标识有界上下文的东西。

聚苯乙烯。为了确保清楚原因,检查有界上下文中的两个链接:   http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.htmlhttp://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx

答案 2 :(得分:1)

我同样地向你发现,加载项目变得很难管理。

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

设置。

在事情变得糟糕的情况下,简单地使事情变得很有帮助。

问题是你在创建另一个项目时会得到什么? (很容易这样做,几乎很容易)

您是否想要独立使用该项目?您可能最终得到的结果.dll如此耦合,您甚至无法在没有完全相同版本等的情况下部署它们。在这种情况下,没有理由将它拆分并使您的IDE混乱)

如果有需要,您可以随时将事物移动到新项目中,这有点痛苦,但到那时候,您将有充分的理由去做它除了完成它之外的感觉。< / p>