Update an entity inside an aggregate

Question

I was reading a similar question on SO: How update an entity inside Aggregate, but I'm still not sure how a user interface should interact with entities inside an aggregate.

Let's say I have a User, with a bunch of Addresses. User is the aggregate root, while Address only exists within the aggregate.

On a web inteface, a user can edit his addresses. Basically, what happens is:

• The user sees a list of addresses on its web interface
• He clicks on an address, and gets redirected to this page: edit-address?user=1&address=2
• On this page, he gets a form where he can modify this address.

I we decided to bypass the aggregate root, this would be straightforward:

• We would directly load the Address with its Id
• We would update it, then save it

Because we want to do it the DDD way, we have different solutions:

1. Either we ask the User to get this Address by Id:

   address = user.getAddress(id);
address.setPostCode("12345");
address.setCity("New York");
em.persist(user);

   The problem with this approach is, IMO, that the aggregate root still doesn't have much more control over what's done with the address. It just returns a reference to it, so that's not much different from bypassing the aggregate.

2. Or we tell the aggregate to update an existing address:

   user.updateAddress(id, "12345", "New York");
em.persist(user);

   Now the aggregate has control over what's done with this address, and can take any necessary action that goes with updating an address.

3. Or we treat the Address as a value object, and we don't update our Address, but rather delete it and recreate it:

   user.removeAddress(id);
address = new Address();
address.setPostCode("12345");
address.setCity("New York");
user.addAddress(address);
em.persist(user);

   This last solution looks elegant, but means that an Address cannot be an Entity. Then, what if it needs to be treated as an entity, for example because another business object within the aggregate has a reference to it?

I'm pretty sure I'm missing something here to correctly understand the aggregate concept and how it's used in real life examples, so please don't hesitate to give your comments!

Judejudea

Answer 1

No, you're not missing anything - in most cases the best option would be number 2 (although I'd call that method changeAddress instead of updateAdress - update seems so not-DDD) and that's regardless whether an address is an Entity or Value Object. With Ubiquitous Language you'd rather say that User changed his address, so that's exactly how you should model it - it's the changeAddress method that gets to decide whether update properties (if Address is an Entity) or assign completely new object (when it's VO).

The following sample code assumes the most common scenario - Address as VO:

    public void ChangeAddress(AddressParams addressParams)
    {
        // here we might include some validation

        address = new Address(addressParams);

        // here we might include additional actions related with changing address
        // for example marking user as required to confirm address before
        // next billing
    }

What is important in this sample, is that once Address is created, it is considered valid - there can be no invalid Address object in your aggregate. Bare in mind however, that whether you should follow this sample or not depends on your actual domain - there's no one path to follow. This one is the most common one though.

And yes, you should always perform operations on your entities by traversing through aggregate root - the reason for this was given in many answers on SO (for example in this Basic Aggregate Question).

Whether something is an entity or VO depends on the requirements and your domain. Most of the time address is just a Value Object, because there's no difference between two addresses with the same values and addresses tend to not change during their lifetime. But again, that's most of the time and depends on domain you're modeling.

Another example - for most of the domains a Money would be a Value Object - 10$ is 10$, it has no identity besides amount. However if you'd model a domain that deals with money on a level of bills, each bill would have its own identity (expressed with a unique number of some sort) thus it would be an Entity.

Shimmy

Thanks. That indeed makes sense, although I'm not sure how to implement a changeAddress() method. The example above is an oversimplification, and an address might be composed of a dozen fields, including street name, building number, LatLng point for the exact location on the map, etc. What do you suggest then, put all these parameters in the method arguments, or create some kind of transient object from the form (would it be an Address object as well?), and pass it as an argument to this method? – Judejudea

I've added sample code for most common scenario. I wouldn't worry about the number of fields - DDD is actually not about the data, it's about the relations and managing complexity. – Shimmy