DDD：地址作为聚合根？
我正在努力设计这个系统，其中地址是最核心的信息。在这种情况下，地址不仅仅是几行字符串。我们存储市镇（代码、名称）、区（邮政编码、名称）、街道（代码、名称）、属于市政的特定地区的街道上的门牌号。这是一个非常标准化的计划。
因此，我们有“Municipal”（市政）、“District”（区）、“Street”（街道）和“HouseNumber”（房屋编号）实体，每个实体都相互关联，定义一个人（或其他东西）的完整地址。
现在我一直在试图弄清楚拥有一个名为 Address 的聚合根是否有意义？地址实体（聚合根）将引用 HouseNumber、Street、District 和 Municipal。然后一个人将与一个地址相关联。
严格来说，这个聚合根不是必需的，但如果我没有它，我将不得不遍历许多对象才能获得完整的地址。基于该参数创建聚合根是否有意义？
在这种情况下，人们永远不会引用除聚合根之外的任何内容，但是 UI 可能仅显示市政当局（在浏览地址等时）。这是否违反了聚合根的思想？
我真的很想听听您的建议并解决这个问题。任何帮助将不胜感激！
关于我的问题的另一次讨论的一点更新：
需要总体管理一些不变量。例如;我 不能在某个地区/直辖市的街道上拥有门牌号，其中 邮政信箱位于另一个不同的区/市。所以赋值的时候 一个地址/人的邮箱，我需要确保它们在同一个 区。
还有一些一致性边界（如果我理解这个概念 正道）。如果我有地址，则该地址必须包含以下地区的门牌号码 一条街道（在该地区）。一条街道可以跨越多个区，所以 确保该街道上的门牌号码正确非常重要 区。
有关设计聚合的更新：
门牌号实际上是地址的入口点。门牌号与街道和地区相关联。因此，一个人与一个门牌号相关联。我还想定义的是，一个人是否对该门牌号负有“邮政责任”。引入聚合根地址，使人与它而不是门牌号相关联。在数据库中，聚合地址将包含与门牌号的 1-1 关联，并且该地址具有与人员的 1-* 关联。我应该在哪里存储表明该人是否有邮政责任的值？我应该在地址聚合中执行此操作吗？或者哪里会 你放了吗？我的实体也是如此 - 我应该在哪里表明此人是否有邮政责任？
I’m struggling designing this system where an address is the most central piece of information. Now in this case, an address is not just a few lines of strings. We’re storing municipalities (code, name), district (post code, name), streets (code, name), house number on a street in a specific district belonging to a municipal. It's a very normalized scheme.
So we have the entities Municipal, District, Street and HouseNumber each with relations to each other, defining a complete address for a person (or something else).
Now I have been trying to figure out if it would make any sense having an aggregate root named Address? An Address entity (aggregate root) would then have references to HouseNumber, Street, District and Municipal. Then a person would be associated to an Address.
Strictly speaking this aggregate root is not necessary, but if I don’t have it, I would have to traverse many objects to obtain the full address. Does it make any sense to create an aggregate root based on that argument?
A person will never reference anything but the aggregate root in this case, however the UI might display only Municipalities (when browsing addresses, etc.). Is this a violation of the aggregate root idea?
I would really like your advice and take on this problem. Any help will be much appreciated!
A little update from another discussion about my problem:
There is some invariants needed to be managed in the aggregate. For example; I
can't have a house number on a street thats in one district/municipality, where
the postal box is in another different district/municipality. So when assigning
a post box to an address/person, I need to make sure that they are in the same
district.
Also there are some consistency boundaries (if I understood this concept the
right way). If I have an address, this must have a house number in a district on
a street (in that district). A street can span multiple districts so it's
important to ensure that the house number on that street is in the correct
district.
Update about designing the aggregate:
A house number is actually the entry point for an address. A house number is associated with a street and a district. So a person is associated to a house number. What I also want to define is if a person has "postal responsibility" for that house number. Introducing the aggregate root Address, makes the person associate with that instead of the house number. In the database, the aggregate Address will contain a 1-1 association to a house number, and the Address has a 1-* to a Person. Where should I store the value indicating that the person has postal responsibility or not? Should I do this in the Address aggregate? Or where would
you put it? And the same goes for my entities - where should I indicate if the person has a postal responsibility?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
要区分地址是值对象还是实体，请问自己一个问题 - 如果一个人的地址发生变化而第二个人有相同的地址 - 两者都会改变吗？如果它们都发生变化 - 地址将提升为实体（因为地址身份很重要而不是价值）。
要区分地址是实体还是聚合根，请问自己一个问题 - 地址本身是否有意义，或者它始终与人联系在一起，通过它进行修改，与它一起删除？如果它不与人联系在一起而是独立存在（在模型中您正在建模而不是现实），那么地址就是一个聚合根。
不，事实并非如此。技术问题不应扰乱您的域名。实体可以作为“子聚合”，地址可以将自治市、城市等结合在一起，但仍然只是一个实体（因为没有人就没有意义）。
演示文稿也不应该扰乱您的域。据我所知 - 如果您仅显示实体列表并隐藏它们所属的聚合，那就完全没问题了。
问题是 - 您想如何对移动过程进行建模？
我看到两种方式：
这意味着您想坚持使用第二种方式（当地址是聚合根时）。没关系，没有任何问题，但您应该重新检查地址是否可以降级为实体，因为这将使您的域模型不那么复杂。
请记住 - 没有“模型”，只有“模型”。您无法对现实进行建模以完美地模仿它，您只能对现实的某些部分进行建模以解决特定问题。
这就是为什么很难回答 ddd 相关问题。
没有人知道您正在努力解决的问题。
这是相关的。如果地址不能在没有人的情况下存在（这不是这里的情况） - 它不可避免地被降级为一个实体（因为没有人它就没有意义）或值对象（如果地址本身没有身份）。否则 - 您只是引入了不必要的聚合根。
如果聚合根包含对其他聚合根的引用（但不包含其他聚合根的实体），那就没问题。因此，地址成分也可以是聚合根（邮局中引用的市政府），并且如果地址本身是实体或聚合根，则不会改变。
To distinguish if address is value object or entity, ask Yourself a question - if person address changes and 2nd person had same address - will both change? If they both changes - address gets promoted to entity (cause address identity is important and not value).
To distinguish if address is entity or an aggregate root, ask Yourself a question - does address make any sense on it's own or it's always tied to person, is modified through it, deleted together with it? If it's not tied with person but exists on it's own (in model You are modeling and not reality), then address is an aggregate root.
No it does not. Technical issues shouldn't mess with Your domain. Entity can work as a 'sub-aggregate', address can hold together municipality, city, etc. and still be just an entity (cause it makes no sense w/o person).
Presentation shouldn't mess with Your domain too. As far as i see - it's perfectly fine if You are showing only list of entities and hiding aggregates they belong to.
Question is - how You want to model that moving process?
I see 2 ways:
This one means that You want to stick with 2nd way (when address is an aggregate root). It's fine and there is nothing wrong, but You should re-check if address can be demoted to entity cause that would make Your domain model less complex.
And keep in mind - there isn't "The model", there are only "A model"s. You can't model reality to mimic it perfectly, You can only model some part of it to solve specific problems.
This is why it's so hard to answer ddd related questions.
No one knows Your problems You are trying to solve.
It is relevant. If address can't exist without a person (which is not a case here) - it's inevitably demoted as an entity (cause it makes no sense without person) or value object (if address itself has no identity). Otherwise - You are just introducing unnecessary aggregate root.
It's fine if aggregate root contains references to other aggregate roots (but not entities of other aggregate roots). Therefore - address constituents can be aggregate roots too (Municipality that is referenced in PostOffice) and that wouldn't change if address itself is entity or an aggregate root.
，就应该创建聚合
与其相关的关系
对象
聚合存储在数据库中，
并且只有根应该是
可以通过查询得到。这
应该获得其他对象
通过遍历关联。
您的场景似乎不满足这两个条件中的任何一个。所以我的意见是不
另请阅读这篇文章并提供答案：DDD：聚合根
Aggregate, in my opinion, should be created if
relationship with its associated
objects
Aggregate are stored in a database,
and only the root should be
obtainable through queries. The
other objects should be obtained
through traversal associations.
your scenario doesn't seem to satisfy either of those 2. so my opinion is no
Also read this post and provided answers: DDD: Aggregate Roots
Address 是否应该是一个单独的实体不应由技术问题驱动。
您谈论地址的方式告诉我它是一个由您提到的组成部分组成的独立实体。
事实上，即使地址没有绑定到 Person 或另一个类，它仍然存在，这也表明它应该是自己的实体。
此外：地址不仅可以被人使用，还可以被其他事物（类）使用。您真的想让每个可以拥有地址的类承担如何从其组成部分形成地址的负担吗？
仅将地址作为一个特定概念来讨论这一事实就足以使其成为一个单独的类。即使在地址仅在与另一个类绑定时才存在的情况下，创建一个单独的类（在这种情况下可能是嵌套类）也是有意义的，只是为了将处理地址的逻辑与逻辑分开处理这个人的其他属性。
更新
如果我理解正确的话（http:// msdn.microsoft.com/en-us/magazine/dd419654.aspx - 关于聚合的部分），那么地址是否可以在没有人（或其他收件人）的情况下存在是无关紧要的；问题是地址组成部分是否可以在没有地址的情况下存在或访问。如果可以的话，地址不应该是聚合根。
一方面，地址应该是其组成部分的集合。但是，地址的组成部分似乎独立于地址，并且可以在没有地址的情况下存在。毕竟，城市或街道可以在没有“门”的情况下存在。因此，我想说，这使地址失去了 DDD 术语中聚合根的资格。
更新
正如汤米提到的（见评论）：更好的问题是“系统是否会直接操纵街道/市政，还是始终是整个地址？”
我认为，从列表中选择一个城市来构建地址并不是“直接操作”，因为它总是在构建地址的上下文中完成。同样，如果仅维护供某个地址使用，我不会考虑维护“直接操纵”的城市列表。
更新
正如 Arnis 指出的那样，Address 是否可以独立于 Person（或其他实体）而存在，这与 Address 本身是否是一个实体有关。据我现在的理解，只有实体才能成为聚合根。
Whether Address should be a separate entity should not be driven by technical concerns.
The way you talk about an address tells me it is a separate entity made up of the constituent parts you mentioned.
The fact that the Address persists even when it isn't tied to a Person or another class, also is a clue that it should be its own entity.
Furthermore: Address can be used not just be a Person, but by other things (classes) as well. Do you really want to burden each class that can have an address to have to deal with how to form it from its consituent parts?
The fact alone that you are talking about an Address as a specific concept is enough to make it a separate class. Even in the case where an address would only exist as long as it is tied to another class, it would make sense to create a separate class, possibly a nested class in that case, just to separate the logic dealing with the address from the logic dealing with the rest of the person's attributes.
Update
If I understand it correctly (http://msdn.microsoft.com/en-us/magazine/dd419654.aspx - the part about aggregates), then whether an address can exist without a person (or other addressee) is irrelevant; the question is whether the address-constituents can exist or be accessed without the address. If they can, Address shouldn't be an aggregate root.
On the one hand an Address should be an aggregate of its constituent parts. But, the constituent parts of an address seem to be independent of address and can exist without it. After all, a municipality or street can exist without a "door" being present in either. So, I would say that this disqualifies Address as an aggregate root in DDD terms.
Update
As Tommy mentioned (see comments): A better question would be "Will the system ever manipulate a street/municipality directly, or will it always be the whole address?"
I would consider that selecting a municipality from a list in order to construct an address isn't "direct manipulation" when it is always done in the context of constructing an address. Similarly, I would not consider maintaining that list of municipalities "direct manipulation" if it is only maintained for use by an address.
Update
As Arnis points out, whether Address can exist independently of Person (or another entity) is relevant in as much as that dictates whether Address is an entity in its own right. As I understand it now, only entities can be aggregate roots.