开始看infoq的mini book时,我以为这不是个问题。Entity就是有主键的对象,Value Object就是immutable class, so easy.
然后就越看越糊涂了。糊涂在于Value Object究竟是个什么东西:按书中所说,Value Object最好是immutable class, 但在某些情况下,比如修改非常频繁,或者创建/删除对象代价很大,也允许mutability。那么,一个mutable Value Object和Entity 对于使用者又有什么区别呢?
如果Entity和Value object区别在于mutability上,使用者只要看看这个class是否implements Entity/ValueObject interface,就知道是否要对修改作同步,是否可以共享。但若mutability只是Value Object的一个可选项,即使给我一个Value Object,我又怎敢放心传出引用而不加同步呢?或者说我应该去看Javadoc,去看API,那么就回到jdk的状态了:只有通过非code的渠道才能知道String/boxing class是immutable class,而没法在code中显示标记出这个事实。
既然如此,Entity 和Value Object这两者根本就不要区分了嘛。对于domain object, interface虽然比parant class要轻很多,但比annotation还是要重,搞两个interface出来却不能带出更好的先验知识,还不如直接用个Imutable的annotation来的好(当然,Java还没强到能够用一个annotation直接把一个类给lock了,我只是假设如果有这个能力的话), 或者干脆不要区分这两个东西来得简单。
另一个角度来看这个问题, ddd sample中,Entity需要实现sameIdentityAs方法,ValueObject需要实现sameValueAs方法,我觉得没必要。equals方法的设计初衷就是表示两个Object是否相等,至于用PK比较还是用attributes比较,是每个class自己的责任,没必要画蛇添足的再分成两个方法吧。实际上, ddd sample的实现中也是让equals调用sameIdentityAs和sameValueAs。我没看到什么地方时equals做不到而那两个方法能作到的,既然如此,根据KISS原则,这两个function就没有存在的价值了。
所以,如果认为Value Object也可以不是immutable,那么区分Entity和Value Object既没有名字上的意义(不能从名字上获得简单直接的信息),也没有方法签名上的差距(实际上这两个接口都应该是dume interface),也就没有区别存在了。所以,论坛上那么多人讨论 XXX是Entity还是Value Object应该换个问法: XXX是不是该作成immutable class?
这个问题我想了挺多天了,和aggregate root的效率一样(下面会写到),是我最不能理解的两个问题。目前的理解就是这样,好像还不是很清楚,再想想吧。
我
分享到:
相关推荐
DDD还涉及到实体(Entity)、值对象(Value Object)和服务(Service)等核心组件。实体是具有唯一标识的对象,它们的状态由其他对象维护。值对象关注的是属性值而不是身份,例如,地址就是一个典型的值对象。服务则...
核心概念包括:领域(Domain)、实体(Entity)、值对象(Value Object)、聚合(Aggregate)、领域事件(Domain Event)和服务(Service)等。在微服务架构中,DDD可以帮助我们将大型系统拆分成一系列小而自治的...
3. **实体(Entity)与值对象(Value Object)**:实体具有唯一标识,其状态由标识和其他属性共同决定;值对象则关注属性的整体值,不具有唯一标识。例如,用户是实体,而用户名和密码可以是值对象。 4. **领域服务...
3. **值对象(Value Object)**:关注于属性值,不具有独立身份的对象,如地址、颜色。它们可以作为实体的属性存在。 4. **聚合(Aggregate)**:一组相关对象的集合,有一个主实体作为聚合根,负责维护内部一致性...
通过领域模型,开发者可以清晰地表达业务逻辑,如实体(Entity)、值对象(Value Object)、聚合(Aggregate)、领域事件(Domain Event)等。 2. **限界上下文(Bounded Context)**:在复杂的系统中,领域模型...
3. **值对象(Value Object)**:描述实体的一个方面,如地址、颜色等,它们自身不具有唯一标识符。 4. **聚合(Aggregate)**:一组相关实体和值对象的集合,是业务规则和操作的边界。在Redux中,聚合通常对应于一...
模型中的关键元素包括实体(Entity)、值对象(Value Object)、聚合(Aggregate)和限界上下文(Bounded Context)。 实体是具有唯一标识的业务对象,它们的行为和状态反映了业务规则。值对象则关注于对象的属性值...
实体(Entity)和值对象(Value Object)是DDD模型中的两个核心概念。实体具有唯一标识,即使属性相同也认为是不同的实例;而值对象则没有唯一标识,它们仅通过其属性值来定义。在实现时,容易将实体和值对象混淆,...
4. **值对象(Value Object)**:表示领域中的一个不可变的概念,关注于数据,不具有身份。 5. **实体(Entity)**:具有唯一标识的领域对象,可以有状态和行为。 6. **工厂(Factory)**:用于创建复杂对象,隐藏...
5. **值对象(Value Object)**:描述实体的属性,关注的是属性值,而非身份。 6. **聚合(Aggregate)**:保持数据一致性的最小单元,由实体和值对象组成,有一个聚合根负责整个聚合的完整性和一致性。 7. **聚合根...
领域驱动设计基础知识 领域服务 聚合及聚合根(Aggregate,Aggregate Root) 实体(Entity) 值对象(Value Object 工厂(Factory) 关联的设计 仓储(Repository)
在描述中提到了一个博客链接,虽然具体内容未给出,但通常博主会分享关于DDD的实践经验和案例,可能包括如何定义聚合(Aggregate)、实体(Entity)、值对象(Value Object)、领域事件(Domain Event)等核心概念。...
服务(Service)、实体(Entity)和值对象(Value Object)是领域建模中的三个基本概念。服务代表领域模型中的行为或操作,它处理不属于任何实体或值对象的业务逻辑。实体是一个由唯一标识符区分的领域对象,它拥有...
在C#中,这通常通过创建具有业务逻辑的实体(Entity)、值对象(Value Object)、聚合根(Aggregate Root)等类来实现。例如,项目可能包含了订单(Order)、商品(Product)和收货地址(ShippingAddress)等领域的...
这包括定义实体(Entity)、值对象(Value Object)、聚合(Aggregate)等DDD的基本构建块。 - **实体(Entity)**:代表具有唯一标识符的对象,通常用于表示业务中的持久化对象,如客户、订单等。 - **值对象...
领域服务则封装了跨越多个Entity或Value Object的业务逻辑。 2. **应用层(Application Layer)**:这一层主要处理用户请求,协调领域层的服务来完成业务流程。它不包含业务逻辑,但负责调用领域层的服务并处理返回...
领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法论,旨在通过将业务领域模型作为软件开发的核心,...在实际项目中,需要根据具体业务场景灵活运用这些知识,不断迭代和优化,才能充分发挥DDD的优势。
领域模型由实体(Entity)、值对象(Value Object)、聚合(Aggregate)、领域事件(Domain Event)等构成,它们共同描绘了业务流程和状态变化。 2. **实体**:实体是具有唯一标识的对象,标识符是其不可变的部分。...
这些实体(Entity)和值对象(Value Object)共同构成了业务模型。 1. **领域模型**:领域模型是对业务领域的抽象,包括实体、值对象、聚合根、领域事件等。在新闻领域,新闻文章可能是一个聚合根,因为它通常是一...
领域模型中的概念包括实体(Entity)、值对象(Value Object)、聚合(Aggregate)、领域服务(Domain Service)等。 3. 聚合设计:聚合是领域模型中的一个核心概念,代表领域对象的集合,它定义了对象的边界,确保...