DDD and Aggregate Transaction Boundary

Question

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?

Answer 1

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.