DDD和汇总交易边界 [英] DDD and Aggregate Transaction Boundary

问题描述

假设我有一个名为document的对象，它有一堆图像，音频，视频等的孩子，所以我的应用程序的用户可以通过输入一些文字，添加图像，视频等来创建文档。我在DDD中了解的是文档是一种聚合，而图像，视频始终以文档为根。基于这一理解，我将如何设计一个使用户能够创建/编辑文档的应用程序？我可以有一个REST端点来上传文件和所有它的孩子在一个请求，但这是潜在的长时间运行的操作。或者，我可以设计2个休息终点，一个用于上传文档的文本体，并重复调用其他的上传子进程，这基本上意味着多个事务。第二种方法还是DDD吗？我通过将文档创建和更新分割为多个请求来违反事务边界？

解决方案

一致性边界（我更喜欢该术语超过事务边界）不是指定允许更改的粒度的概念。他们告诉你什么可以原子地改变，什么不能。

例如，如果您将文档设计为与图像不同的聚合，则不应在一个用户操作中更改文档和图像（即使在这在技术上是可能的）。这意味着聚合不能太小，因为这对用户来说过于严格。然而，他们应该不会太大，因为只有一个用户可以一次更改聚合，所以较大的聚合往往会产生更多的冲突。

尝试设计尽可能小的聚合，但仍然足够大以支持您的用例。因此，您必须根据上述规则为您的应用程序确定自己。

所以你提到的两种方法都是从DDD的角度来看是有效的。

Let's say I have an object called document and it has bunch of children in form of images, audio, video etc. So a user of my application can create a document by typing some text, adding image, video, etc. From what I understand in DDD, document is an aggregate, while images, videos are always associated with a document as root. Based on this understanding, how would I design an app that enables a user a create/edit document? I could have a REST endpoint to upload document and all it's children in one request, but that's potentially long-running operation. Alternatively, I could design 2 rest endpoint, one to upload document's text body and call the other repeatedly to upload its children, which essentially means multiple transactions. Is the second approach still DDD? Am I violating transaction boundary by splitting document creation and update into multiple requests?

解决方案

Consistency boundaries (I prefer that term over "transaction boundaries") are not a concept that specify the granularity of allowed changes. They tell you what can be changed atomically, and what cannot.

For example, if you design your documents to be separate aggregates than the images, then you should not change both the document and the and image in one user operation (even when that's technically possible). This means that aggregates cannot be too small, because that would be overly restrictive for a user. They should however also not be too big, because only one user can change an aggregate at a time, so larger aggregates tend to produce more conflicts.

You should try to design aggregates as small as possible, but still large enough to support your use cases. Thus, you'll have to figure that out yourself for your application with the rules above.

So both approaches that you mention are valid from a DDD point of view.

这篇关于DDD和汇总交易边界的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！