解决困境
我有 Person 聚合，其中 Address 是 vo 的一部分，但现在我有另一个聚合 Payment，其中有另一个 VO PaymentInfo ，其中包含信用卡号码和其他详细信息等详细信息，但现在我需要 PaymentInfo VO 中的帐单地址和送货地址。现在，由于地址是个人不可或缺的一部分，我无法使用它。
所以我要做的，
在付款聚合中创建单独的地址 Vo 并将其用作帐单地址和送货地址。
将地址移入单独的聚合并在 PaymentInfo 和 Person 中引用它。
在 Person 本身中创建两个地址并在 PaymentInfo Vo 中引用它。
请帮帮我吗？
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 ,
Create separate Address Vo in Payment aggregate and use it as billing address and Shipping Address.
Move address in to separate aggregate and reference it in PaymentInfo and Person.
Create two addresses in Person itself and reference it in PaymentInfo Vo.
help me please ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里重要的是 - 值对象没有身份。
这意味着 - 它们可以轻松地在实体之间共享。
我的意思是 - 不应该共享特定实例，而是应该共享它们的类，输入
Address而不是“UK，London street 'whatever' 16”。值对象实例不应该永远被共享（同样 - 因为它们没有身份，它们的状态是定义它们的）。因此，在你的位置 - 我会确保
地址作为一个概念对于人和付款信息来说是相互普遍存在的（它们必须具有相同的结构），将其移动到正确的文件夹/命名空间中，这样我就可以看到它共享并将其用于两个实体。如果它们不是普遍存在，我会将
Address重命名为PersonAddress并创建第二个 -PayerAddress（名称可能会根据您的业务而有所不同）造型）。从提供的链接引用杰夫：
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
Addressinstead 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
Addressas 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
AddressasPersonAddressand create second one -PayerAddress(name might differ according to Your business You are modeling).Quoting Jeff from provided link:
我会接受它无处不在的本质。不要将个人地址类引用到帐单地址和送货地址。
可以轻松实现两件事。一是您可以从业务分析师那里获得沟通优势，二是编码将是明确且易于理解的。
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.