REST new ID with DDD Aggregate

Question

This question seemed fool at first sight for me, but then I realized that I don't have a proper answer yet, and interestingly also didn't find good explanation about it in my searches. I'm new to Domain Driven Design concepts, so, even if the question is basic, feel free to add any considerations to it.

I'm designing in Rest API to configure Server Instances, and I came up with a Aggregate called Instance that contains a List of Configurations , only one specific Configuration will be active at a given time.

To add a Configuration, one would call an endpoint POST /instances/{id}/configurations with the body on the desired configuration. In response, if all okay, it would receive a HTTP 204 with a Header Location containing the new Configuration ID.

I'm planning to have only one Controller, InstanceController , that would call InstanceService that would manipulate the Instance Aggregate and then store to the Repo.

Since the ID's are generated by the repository, If I call Instance.addConfiguration and then InstanceRepository.store , how would I get the ID of the newly created configuration? I mean, it's a List, so It's not trivial as calling Instance.configuration.identity

A option would implement a method in Instance like, getLastAddedConfiguration , but this seems really brittle.

What is the general approach in this situation?

Answer 1

the ID's are generated by the repository

You could remove this extra complexity. Since Configuration is an entity of the Instance aggregate, its Id only needs to be unique inside the aggregate, not across the whole application. Therefore, the easiest is that the Aggregate assigns the ConfigurationId in the Instance.addConfiguration method (as the aggregate can easily ensure the uniqueness of the new Id ). This method can return the new ConfigurationId (or the whole object with the Id if necessary).

What is the general approach in this situation?

I'm not sure about the general approach, but in my opinion, the sooner you create the Ids the better. For Aggregates, you'd create the Id before storing it (maybe a GUID), for entities, the Aggregate can create it the moment of creating/adding the entity. This allows you to perform other actions (eg publishing an event) using these Ids without having to store and retrieve the Ids from the DB, which will necessarily have an impact on how you implement and use your repositories and this is not ideal.