我正在使用DDD模式开发在线工作门户。 我发现了很多“对象”，例如用户，工作，角色，专业知识，体验范围，国家/地区，州，城市，地址，订阅等。
我的问题是我如何确定这些是实体，价值对象还是集合？如果遇到同样的难题，请告知我。
我已经做出以下决定：
实体-用户，工作，SubscriptionPackage ValueObjects-角色，专业知识，体验范围，城市，州，国家/地区
我知道在进行DDD建模时我们不应该考虑持久性，但是一个疑问浮出水面，无论我存储在数据库中的哪个值对象都应该具有ID？
如果它们具有ID，是否不违反ValueObjects的基本原理，并且如果我们不使用ID保存它们，那么如何在外键字段中引用它们？
请帮助我回答这些问题。
如果您可以建议上面提到的哪些对象是实体，哪些是价值对象以及哪些是合计的。
提前感谢
答案 0 :(得分：2)
在考虑DDD时，将DB映射留到以后的阶段。我知道我在重复你说的话，但这仅仅是因为这是真的。值对象可能出于其他原因（规范化，报告等）而具有数据库ID。
首先提出您的对象模型，然后找出如何映射它。在某些（罕见）情况下，如果有些东西太贵而无法正确映射，则可能需要稍微更改对象模型（我想不出一个例子，但我不想成为极端主义者）。
因此，再一次，不用考虑数据库-考虑对象。实体出于什么原因拥有ID？我会说，这样以后可以在保留相同ID的情况下对其进行检索和修改。 如果它是VO，则是因为该标识隐含在对象的值中。用户拥有ID是否有意义？地址呢？还是城市？...取决于。
以城市值对象为例，如果您需要将其作为FK映射到“ cities”表，则您的City对象可能会有一个ID，但不会公开该ID。这是实现的细节。而用户ID将被公开。例如，一个城市可能链接到一个省/州，而一个国家/地区。
但是在另一个应用程序中，用户可以在其中添加城市和有关城市的信息，该城市可能是一个实体，甚至是一个集合。这真的取决于您的要求。
话虽如此，您提供的实体和VO的列表通常看起来不错，但我不知道您的要求。
要回答第一个问题：您可以阅读Entities, Value Objects, Aggregates and Roots，因为对于VO，实体或聚合有一些规定。困难来自如何应用它们，而经验就是解决问题的方法。
摘要：
许多对象并不是从属性上定义的，而是由连续性和身份性来定义的。
许多对象没有概念上的标识。这些对象描述了事物的特征。
集合在一个或多个实体周围划定了边界。聚合为其支持的任何操作为其所有实体强制执行不变式。