DDD值对象

刚开始的时候Entity和VO很容易混淆，分不太清楚，不过在实际使用之后有了一些个人的想法，先不管对错，贴出来探讨一下。 banq老师说VO是不能更改的，只能整体替换，这个我现在还没有理解。我自己从另一个角度的理解：VO关乎于对象的粒度，VO来源于

关于不变性设计，其实很早前就存在，但由于当时并多线程和多核并未普及，而且软件的性能可通过直接升级计算机得以提升，也使其并未得到关注。但对于曾经多线程编程人员来说，这是相当深刻的。 不变性即不会改变，对于程序员表达一个变化的世界是不可思议的。在对象学上，这是

今天，我们将讨论DDD意义上的标识与数据库主键之间的区别。 我们经常将两者混合在一起，但它们真的是一回事吗？实体标识在DDD的背景下，标识是实体固有的东西。 只有实体拥有它; 它是用于区别于所有其他实体的唯一标识它们自己的东西。例如，

Google发布了值类型Java的开源库包AutoValue 1.0。方便使用Java创建值类型。 什么是值类型value

本文想澄清DTO与Value Object与POCO的区别，其中DTO代表数据传输对象，而POCO是Plain Old CLR Object，在Java环境中也称为POJO。对Value Object做一个注释：C＃中有一个类似的概念，即Value Type。它只是对象如何存储在内存

VO，全称Value Object，中文名值对象。 我们平常说的Object一般是Reference Object，这是带有实体意味的。而VO相对于RO，有很大对立性。 1、没有所谓的唯一标识，若果真要说唯一标示

我们的业务系统就类似一个小区（appSystem），一个小区中有很多资源，对小区中的所有资源按照类型进行树形的分类就是资源类型（resourceType），比如“停车位”是一种类型的资源、小区中的“绿化树”是一种类型的资源、小区中的“人”是一种类型的资源、“保安”是一种类型的资源、小区中的“业主”是

为了定义实体和值对象之间的差异，我们需要引入三种类型的相等性，当我们需要将对象相互比较时，它们会起作用。引用相等意味着如果两个对象引用内存中的相同地址，则认为它们是相等的。标识符相等性意味着类具有id字段。如果具有相同的标识符，则此类的两个实例将是相等。</

在看DDD时，说到 值对象不可以改变，于是就可以共享。如果 值对象相同就都可以保持对它的引用，达到少创建值对象。如下 假设，一个User 实体，Address是它的值对象

好久不见，大家还好吗？我今天又遇到一个问题，还想求教，望指点一二。现在项目组在做一个物流项目，有一个检索商品的功能，我把商品抽象成了一个实体（ITEM），它含一个叫MANUFACTURE属性，MANUFACTURE是一个MASTER表，内面只有CODE和NAME，用户可以POPUP一

在聚合1中，对象A是一个实体对象，在聚合2中，对象A是一个值对象，这种情况，在模型中该如何设计？是为聚合1，聚合2分别定义对象A，还是他们可以重用同一个对象A？例如，在汽车这个聚合中，因为需要对每个轮胎进行跟踪，所以需要区分这些轮胎，因此，在汽车聚合中，轮胎是实体对象，在这个聚合中，它们需要

1.ProductId, BacklogId 之类的“值对象”真的有必要存在,为什么？明明只是一些简单的id，非要变成各种所谓的VO，到底是为哪样？让UML看起来更像“聚合”？ 2.“小聚合” 、“按id引用”，真的那么合理？发现很多讨论ddd的地方，一旦

楼主，事实上我看了帖子后还是比较混乱，不明白immutablity是怎么解决并发问题的，请楼主指教。 我看了帖子后大概理解是，值对象类似于栈上的值数据，只有自己的线程可以访问和修改，不同线程拥有的实际上是不同的实例，那么自然不存在争用问题，

在业务系统中，会使用很多元数据，比如某些论坛注册需要选择国家，总不可能将全世界所有的国家名称和代码都建立成枚举，这种应用一般都是将这些国家建立成数据库端的元数据表，这种元数据映射到系统中肯定是VO，这点是肯定的，而且这种VO可能在多个领域聚合中都有可能引用到，那如何来对这种数据进行加载呢？因为每个仓

现在有一个需求是这样的： 每月计算特定人员的报酬，每个人可能有不同的报酬项，报酬项是可以由用户自定义的，报酬项包括计算公式。现在计算公式中可能会使用到一些相对固定的常量。 为什么说是相对固定呢？因为它不是简单的某

比如权限这块 我们有user 、role 和userrole 聚合根，userrole里面的userID roleID 是不是指对象