Question

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

我一直在转向以下概念：

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专家如何考虑企业级应用程序。请随时推荐书籍和文章。

提前谢谢！

Answer 1

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

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

Answer 2

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

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

Answer 3

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

我更喜欢

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

设置。

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

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

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

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

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

3 个答案: