Spring Data REST - How to update entities in child collections of aggregates

Question

Following the principles of DDD and using Spring Data REST/HATEOAS what is the best way to manipulate entities in child collections.

For example:

@Entity
public class Topic{

  @Id @GeneratedValue
  private Long id;
  private String title;

  @OneToMany
  private Set<Post> posts;
  …
}

@Entity
public class Post{

  @Id @GeneratedValue
  private Long id;
  private String title;
  private String body;

  @OneToMany
  private Set<Comment> comment;
  …
}

@Entity
public class Comment{

  @Id @GeneratedValue
  private Long id;

  private String text;

}

Spring Data REST (SDR) inlines domain objects that don't have their own repositories when serializing to JSON.

{
  "title" : "Spring",
  "posts" : [{ 
    "title": "Spring Boot 1.5.8",
    "body": "blah",
    "comments":[ {"text":"great!"} , {"text":"boo"}, 
        {"text":"comment that should be removed by moderators"}]
  }]
  "_links" : {
    "self" : {
      "href" : "http://localhost:8080/topics/1"
    }
  }
}

The issue I have is that I am unable to get a handle on individual objects in a collection because SDR not only hides ids for all entities but also does not provide a 'self' link for inlined entities.

I don't want to simply PUT the whole aggregate because inline with DDD I want to handle changes of state via dedicated 'controller' resources, allowing the raising of event to trigger additional business logic. Consider adding/removing/updating a post comment in the example above.

I'm left with an number of options none of which I really like.

1. Reverse all my unidirectional relationships and create repositories for all the child entities, effectively abandoning the DDD aggregate design concept.

2. Move to bi-directional relationships, create repositories for all child entities and compose the aggregate using a Projection. The general advice from the internet (including SDR developer Oliver Gierke) is to avoid bi-directional relationships if at all possible due to performance considerations and having to manually manage the relationship.

3. Add a GUID or some other immutable unique identifier to the child entities. This feels wrong considering the whole point of HATEOAS is that the URI is the identifier. Even this breaks down when dealing with children of children.

I'm currently feeling inclined towards 2 as it seems to be the only workable option that allows me to retain the design principle.

Has anyone encountered and overcome a similar problem?

Edit:

I've come up with a possible solution:

Move to bi-directional relationships without creating repositories for child entities. This will give me the parents key so that I can compose a 'self' & other links using a ResourceProcessor e.g /topics/1/posts/add-post which I can handle via a RestController. This should work well enough at 1 level deep, it may have performance implications for deeper nesting e.g. /topics/1/posts/1/comments/add-comment as with JPA there's going to be a cost associated with doing the lookups to traverse the parent relationships. This would be done in tandem with @Alan Hay's solution to exposing Id's where there is no natural key in the entity.

This approach maintains DDD & HATEOAS at the cost of going against advice on bi-directional relationships.

Thoughts?

Answer 1

It is possible to add _links to resources that are not mapped through repositories. To add an action deleteComment, for instance, you should configure a @Bean like this:

@Bean
public ResourceProcessor<Resource<Comment>> commentProcessor() {
    return new ResourceProcessor<Resource<Comment>>() {
        @Override
        public Resource<Comment> process(Resource<Comment> resource) {
            resource.add(linkTo(methodOn(MyCustomController.class).deleteComment(resource.getContent().getId())).withRel("deleteComment"));
            return resource;
        }
    };
}

You should get the link of the action on the Comment object inside the Post