Domain driven design DDD与避免积垢

在我读过的大多数文章中，似乎在DDD中要避免CRUD，因为我们处理的是业务流程建模，而不是数据建模。然而，我发现很难在某些实体上不进行CRUD操作。例如，在学校评分系统中，在教师给学生评分之前，必须有一个学年或者一个评分周期。我看不出没有CRUD我们如何管理分级周期。有人能告诉我这一点吗？

DDD的一个非常重要的部分是有界上下文

有界上下文是应用程序中术语一致的有界部分。DDD很少是整个应用程序的正确方法。因此，我们通常在单独的有界上下文中划分应用程序。在每个有界上下文中，可以有不同的模式。例如，CRUD用于域复杂度非常低的BC，DDD用于域复杂度较高的区域

根据sé，不能避免积垢。当存在复杂的业务规则时，应避免CRUD。当您使用很少的规则在数据上提供表单时，应该避免DDD

因此，有可能有一个应用程序，其中一些部分执行简单的CRUD，而另一些部分使用更丰富的域模型

这是等式的一部分，回到你最初的问题：

“在教师给学生评分之前，必须有一个学年或一个分级期”

这里您暗示创建学年是一个CRUD操作，您可能已经在考虑

“插入学年…”

。这是一种可能性（您可以通过使用有界上下文来实现，见上文）。 如果没有太多的域逻辑，那么对该部分使用CRUD是可以的

---

然而，您需要确定“插入新学年”是否实际上不是“开始新学年”的技术术语。DDD强调语言。如果您确定新学年的开始有很多附加规则，并且需要复杂的代码，那么您可能应该将其放入您的域中。因此，如果你的领域专家一直告诉你他们是如何“开启新学年”的，那么你应该在你的领域中为这种行为建模。因此，您不应该将其称为“InsertNewSchoolYear”，而应该将您的方法称为“OpenNewSchoolYear”。无论最终是否会在数据库中插入，这都是无关紧要的，您希望在您的模型中捕获特定的领域知识。

您好Kenneth:谢谢您的回答，它澄清了我的一些想法。但问题是，正如你所说，如果需要的话，我可以加入积垢；如果我这样做，它是否应该总是在一个单独的BC中？我不建议这样做。在一个BC内，你应该尽可能保持你的语言干净。如果在同一个BC中有

InsertSchoolYear

和

gradetest

，可能会让人困惑。但是，没有什么可以阻止您在一个BC（CRUD）中插入

InsertSchoolYear

，在另一个BC中插入

SchoolYear

，即使它们连接到相同的数据（数据库表或视图或…），域中的任何内容都应该是数据存储无关的。谢谢，我将根据您的解释尝试一些事情。@Kenneth，但您不应使用相同的数据库集成BCs。它们应该通过某种API或域事件/消息进行通信。