DDD -如何从[HttpPut] RestAPI中的失败中更新模型？

Question

我正在学习DDD，所以如果这个问题太天真，我很抱歉。假设一个应用程序管理在DDD之后开发的用户发布，并使用RestAPI进行外部交互(例如，对于任何前端层)。

看看Publication模型，我们就会有ApplyLike、RemoveLike、Comment等行为。

现在假设我们被要求通过来自RestAPI的http-put请求实现(尚未实现或设计)更新现有出版物的功能。出版物的作者应该能够修改它的大部分字段(如标题、正文、附件等)。

我应该如何设计在Publication模型中更新现有发布的行为？

对我来说，我能想到的解决方案显然是错误的，它们是A:创建一个Update方法，所有的方法都只设置模型的所有可更新字段(最终会有一个巨大的参数列表，并且只会为几乎所有的模型字段公开一个毫无意义的公共唯一的setter访问器) B:接受选项A的失败，然后为模型字段公开公共设置器，这样用户就可以随意修改了，最后，C:违反层分离，只是假设更新DTO作为我们域的一部分，并创建一个Update(PublicationDTO)方法(这是错误的，因为我们的前提是不正确的-这个DTO不属于这个域)。

我认为这可能更像是一个面向对象的问题，而不是一个DDD问题，但我应该如何处理这个问题呢？也许我应该有不同的行为，像ChangeTitle，ChangeBodyText？

Answer 1

你正在努力解决这个问题，因为你把一个CRUD问题融入了DDD。

思想过程中缺少的是无处不在的语言--在业务语言中使用的术语和表达的功能。

你没有使用商业人士所使用的语言。他们永远不会使用像ApplyLike或RemoveLike这样的术语--它们可能会被命名为Like和Unlike。

以同样的方式思考，当领域足够复杂时，几乎总是有一个原因和/或过程来改变出版物中的某些内容。当用户更改标题时，是否应该通知其他已经使用该出版物的用户？当正文文本发生变化时，是否需要再次对其进行索引以进行搜索？添加新附件时，是否需要对文件进行后处理并将其转换为另一种格式，例如PDF？这些行为将反映出这一点- UpdateContent、AttachReferenceDocument、Publish等。

正如您所看到的，当您的域足够复杂时，这些行为将驱动应用程序的命名和结构。您很少会有任何名称简单的更新。

对于发布的示例问题，您可能应该从CRUD设计开始，并在必要时将域充实到DDD/CQRS模式。