银行应该是实体还是价值对象
首先要问的问题是：您需要为银行建模吗？
域驱动设计，我试图从数学上而不是直观上找出某种区别。在我当前的项目中，我们在payment之间进行某种banks传输。在此系统中，银行的承载方式不像实体建筑物，而是抽象的bank。它肯定具有BankCode，country和Bank Name。问题是：Is the bank should be an entity or value object。我凭直觉认为它应该是实体，但有人说它可能像价值对象。
据我所知，entities可能具有相同的属性，但仍然不同。另一方面，value objects不得具有identity，如果所有属性都相同，则它们应该相同，它们应该回答它们是什么，而不是它们是谁。请如果我错了-纠正我。
[在系统中，banks在任何流程中都不会改变，就像另一个值对象Country或Currency，也许我们可以说，具有相同银行代码，名称和国家/地区的银行是相同的银行。可以说，具有相同国家代码（ISO格式）的Country是相同的。但对我而言，我仍然觉得它们是实体。有人可以证明我错了，并提供数学证明它们应该是Value对象还是Entities。
[目前，我最终得出的结论是：“ The one difference between Entity and Value Object is the entity can contain the all same attributes and still be different, the Value Object can't”，就像交易和人可以具有相同的数量和商品，相同的名称，但仍然不同，并且如地址，国家，城市和房屋应该相同数量是相同的。请纠正我，也许还有更多差异
在您的情况下，bank应为Entity，因为每个银行都有一个唯一的BankCode来标识它。即使此时您的系统不更新存储库，也不意味着将来将无法使用。
例如，如果银行的某些属性发生更改，那么您所更改的其他任何内容都是其总公司地址（刚刚编成……），则唯一标识该银行的代码将保持不变，因此，同一银行，但是使用不同的总公司地址。
此库BankCode: 1234, Location: US Texas和Location属性BankCode: 1234, Location: US Colorado中的更改后的此库仍然是同一事物。
给出数学定义很困难，因为数学大约是值。
这种基于不在属性上的属性>>]的唯一性，但是基于某种Identity，它随着变化而保持不变，更接近现实世界的工作方式，因此很难赋予-它的直观定义。
这是数学中ValueObject的一个很好的例子。假设您使用向量和矩阵为3D数学库建模。 Vector和Matrix为ValueObjects。
假设我们有两个向量：
您确实有两个向量，但是从数学角度来看，它们是相同的，即代表相同的事物并且相等。矩阵也是如此。
让我们有一个转换T（例如翻译）。在数学上，您拥有的是：
v3 = T（v1，v2）
当您应用此转换时，您将获得一个全新的向量。结果，此向量我们可能与v1和v2具有相同的坐标，因此它们将相等，但是您请勿更改
v1或v2。假设您理发了，也说这也是一种转变。如果在现实世界中这是真的吗？
You2 = T（美发师，You1）
不，不是。仍然是使用其他发型的人，应用变换时不会创建其他发型。
根据系统，概念何时既可以是值又可以是实体的一个好例子是在建模Money时。在进行银行转帐的情况下，您需要在帐户之间进行转帐。在这种情况下，Money是ValueObject，因为您无需区分5 $和5 $，它仍然是相同的金额
假设您去商店买了一杯饮料，这是5美元。如果您有两个$ 5的Banknotes，则使用哪一个支付都没关系，因为它们表示相同的amount] >>。
另一方面，每个Banknote都有一个序列号。这两个5 $ Banknotes将具有不同的序列号，从而使它们唯一且不同，因此它们是Entities。
如果系统跟踪Banknotes，则将其建模为Entity。如果不是，则将其建模为ValueObject。
向量和矩阵上是否有序列号或任何种类的身份？您的车（如果有的话）可以。如果您去有很多车的停车场，而您的两辆车和其他人的车是完全一样的，那么您是否在意哪一辆呢？好吧，最好带走你的，否则，它会偷窃并且是违法的，有人对此会不高兴。
让我们再次获取向量和变换T。
[T（v1，v2），T（v2，v2）和T（v1，v1）都给出相同的结果，因为这两个向量相等，我们不在乎使用哪个向量。
银行应该是实体还是价值对象
首先要问的问题是：您需要为银行建模吗？
特别是，您是否控制银行更改规则？还是您只是在管理其他机构提供给您的信息的本地缓存/存储库（以与ISO 3166维护机构提供给我们的国家/地区代码信息相同的方式）。
域驱动设计中的一个重要原则是要小心以确保您正在建模应该建模的对象。
我们可以说，具有相同银行代码，名称和国家/地区的银行是相同的银行。我们可以说具有相同国家代码（ISO格式）的国家/地区是相同的。但对我而言，我仍然觉得它们是实体。
是。银行当然是实体。国家也是如此。
但是它们是现实世界中的实体。您的域模型不拥有它们。数据存储区中的内容是有关这些实体的本地缓存信息。
例如，ISO-3166-1标准是活动文档；它在2020年3月2日进行了更改（对MK的全名进行了更正）。给定的国家/地区代码和日期
为您提供了固定的标识符。由于国家/地区代码保留了50年，因此对于不重要的时间段，仅国家/地区代码就不会明确。令牌MK当然是一个值对象。表示令牌MK的查找表表示North Macedonia是一个实体。但是...它是一个稳定的实体，因此在某些情况下，我们也许可以将其视为固定的。
不过，除非您自己为ISO 3166 / MA做工作，但这不是
您的
实体。您所拥有的信息只是副本。我的猜测也是您的银行代码也是如此。域驱动设计的一部分：如果我们进行工作以确保我们真正了解我们要建模的实际业务问题，那么我们的后续实现将与我们想要的目标保持一致，并且容易面对新要求进行更改。
这是说，您确实需要确保您在域的上下文中了解“银行”，以确定它是实体还是价值对象。
银行应该是实体还是价值对象
首先要问的问题是：您需要为银行建模吗？