C# ASP.NET 3.5项目管理系统的领域驱动设计方法

Question

我正在写一个简单的项目管理系统，使用SQLServer3.0和ASP.NET 3.5与SQL Server2008 R2后端。

目前，它基本上是一个数据驱动的应用程序，具有基本的CRUD功能，少量的业务逻辑和一些验证。

预计系统将增长到包含更复杂的业务功能，我有兴趣尝试使用域驱动设计(DDD)的原则对其进行重新建模。

我意识到这对目前的系统来说有点过头了，我预计现在会创建一个贫血域。

该系统由客户、客户、项目、组件和活动组成。

一个客户有0、1或多个客户端。客户有0、1或多个项目有0、1或多个组件，A组件有0、1或多个活动。

我该如何使用DDD对此进行建模？我是将Customer、Client、Project、Component和Activity作为聚合根，还是拥有一个聚合Root (客户)并将Client、Project、Component和Activity作为可通过Customer访问的实体？有没有推荐的方法来对实体/聚合根之间的多对一关系进行建模？

我意识到这并没有涉及到值对象(显然Customer，Client等包含几个属性)等，但我在这里是一个完全的初学者，我喜欢一些指针，就像一个接近完整的答案一样。

对于这个问题的开放性，我很抱歉，我已经有了一个工作系统，但我正在展望未来。

谢谢，瑞奇。

Answer 1

领域驱动设计的核心不是软件分析，而是业务分析。应用DDD的思想和模式可能会让您最终得到根本不被称为客户、客户、项目、组件和活动的聚合和实体。

预先假设一组给定的类/实体，并尝试在它们上强制使用DDD构建块，可能不会很快得到任何结果。

对于初学者，我只能推荐(重新)阅读Eric Evans的《领域驱动设计》一书。不仅是前几章，后面的部分(第三部分-重构到更深层次的洞察和第四部分-战略设计)比处理低级构建块的更具战术性的第二部分要重要得多。

如果你只想做一个建模练习而不想做耗时的分析(这使得非常昂贵并且只适用于复杂的领域)，我推荐阅读Streamlined Object Modelling: Patterns, Rules, and Implementation 。

Answer 2

通常我把所有这些类型的元素作为聚合根，你不能看到模型的未来增长或变化，如果你需要访问活动作为一个独立的实体，例如做一个活动报告，按活动类型分组和按月分段，并制作一个子报告来分解客户或客户的信息，从这一点上尝试从客户-客户-活动中制作一份报告是困难的，并且你需要添加一些代码来处理响应和制作报告。

您可以认为客户a是根，但不要避免引用childs实体上的父实体，我认为这是不令人头疼的最佳实践。