1

我正在使用带有 SQL Server 2008 R2 后端的 C# 3.0 和 ASP.NET 3.5 编写一个简单的项目管理系统。

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

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

我意识到这对于系统目前的状态来说太过分了，我预计现在会创建一个贫血的领域。

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

一个客户有 0,1 个或多个客户。客户有 0,1 或许多项目 项目有 0,1 或许多组件，组件有 0,1 或许多活动。

我将如何使用 DDD 进行建模？我是否将客户、客户、项目、组件和活动作为聚合根，或者我将拥有一个聚合根（客户）并将客户、项目、组件和活动作为可通过客户访问的实体？是否有推荐的方法来建模实体/聚合根之间的多对一关系？

我意识到这并没有涉及值对象（显然客户、客户等包含多个属性）等，但我在这里是一个完整的初学者，并且会喜欢一些指针，就像一个接近完整的答案一样。

为这个问题的开放式性质道歉，我已经有了一个工作系统，但正在展望未来。

谢谢，里奇。

4

2 回答 2

3

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

假设一组给定的类/实体并尝试在它们上强制执行 DDD 构建块可能不会让您很快取得任何进展。

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

更新：如果您只想进行建模练习而不进行耗时的分析（这使得 DDD 如此昂贵且仅适用于复杂领域），我建议您阅读Streamlined Object Modelling: Patterns, Rules, and Implementation。

于 2012-09-04T11:35:18.043 回答
0

通常我把所有这些类型的元素作为聚合根，你看不到模型的未来增长或变化，如果你需要作为一个独立实体访问活动，例如按类型对活动进行报告活动并按月细分，并制作子报告以按客户或客户展开信息，从这一点开始尝试从客户那里制作报告 - 客户 - 活动很难，并确保您需要添加一些代码来处理响应并制作那个报告。

您可以在客户中考虑根，但不要避免在子实体上引用父级，我认为这是不头痛的最佳做法。

于 2012-09-04T11:45:12.787 回答