Address dilemma

I have Person aggregate in which Address is part and vo , but now i have another aggregate Payment which have another VO PaymentInfo , which contains details like Creditacard number and other details, but now i need Billing Address and Shipping Address in PaymentInfo VO. Now since Address is integral to Person i cannot use that.

So what i do ,

1. Create se开发者_运维知识库parate Address Vo in Payment aggregate and use it as billing address and Shipping Address.

2. Move address in to separate aggregate and reference it in PaymentInfo and Person.

3. Create two addresses in Person itself and reference it in PaymentInfo Vo.

help me please ?

---

Important thing here is - value objects have no identity.
That means - they can become shared between entities easily.

With that I mean - not particular instances should be shared, but their classes, type Address instead of "UK, London street 'whatever' 16". Value object instances should never be shared (again - cause they got no identity and their state is what defines them).

So in Your place - I would make sure Address as a concept is mutually ubiquitous for person and for payment info (they must have same structure), move it into right folder/namespace so I could see that it's shared and use it for both entities.

If they aren't ubiquitous, I would rename Address as PersonAddress and create second one - PayerAddress (name might differ according to Your business You are modeling).

Quoting Jeff from provided link:

There's no problem with 2 aggregate roots referencing the same entity - they just can't reference another aggregate's internals. It is different for value objects, which are simpler. Consider how you can reference dates, like "August 20th, 2010," any number of times in your classes.

---

i will go with ubiquitous nature of it. Dont reference the Person address class to the billing address and the shipping address..

Two things Can be achieved easily .one is the communication benefit which you can get in the business analyst and second is the Coding will be explicit and understandable.