DDD设计规范下，删除Post的Review需同时传递聚合根与实体ID吗？

Great question—this is such a common sticking point when you’re first getting your feet wet with DDD aggregates! Let’s break this down clearly.

First off, your core understanding is spot-on: since Post is the aggregate root, all operations involving Review (including deletion) must go through the Post aggregate. That means you do need both the aggregate root ID (post ID) and the entity ID (review ID) in your HTTP DELETE request.

Here’s why this makes sense:

• To follow DDD rules, you can only load aggregates by their root ID. So you first fetch the entire Post aggregate using its ID—you can’t directly query for a Review on its own (since it’s not an aggregate root).
• Once you have the Post, you let the aggregate handle the deletion logic internally. This ensures you maintain the aggregate’s business invariants: maybe deleting a review requires checking if the user has permission, updating the post’s average rating, or triggering a domain event like ReviewDeleted—all things the Post should manage, not some external service.

A typical RESTful endpoint for this would look something like:

DELETE /posts/{postId}/reviews/{reviewId}

And the backend logic (pseudocode) would follow this flow:

// Example in C#
public async Task DeleteReviewAsync(Guid postId, Guid reviewId)
{
    // Only fetch via aggregate root
    var post = await _postRepository.GetByIdAsync(postId);
    if (post == null)
        throw new NotFoundException("Post not found");

    // Let the aggregate handle the deletion (enforces business rules)
    post.DeleteReview(reviewId);

    // Save the entire aggregate (since aggregates are saved as a unit)
    await _postRepository.SaveAsync(post);
}

Skipping the post ID and trying to delete a review directly by its ID would break DDD’s aggregate boundary rules—you’d be bypassing the aggregate root’s control, which could lead to inconsistent state or violated business logic.

Remember: Aggregates are consistency boundaries, so all changes to entities inside the aggregate must be orchestrated by the root. This keeps your domain model robust and aligned with real-world business rules.

内容的提问来源于stack exchange，提问作者Doğaç Özen