领域驱动设计

本文深入探讨了领域驱动设计(DDD)的基本元素,包括实体(Entity)、值对象(Value Object)、服务(Service)、聚合(Aggregate)、工厂(Factory)和仓库(Repository)。此外,还详细介绍了限界上下文的概念,如Shared Kernel、Customer/Supplier、Conformist、Anticorruption Layer、Separate Way、Open Host Service和Published Language,阐述了它们在DDD中的角色和最佳实践。
摘要由CSDN通过智能技术生成

基本元素

导航图

导航图

Entity

很多对象不是通过他们的属性定义的,而是通过连续性和标识定义的。

举例:
一个人有一个标识,这个标识会陪伴他走完这一生。他的名字可能改变,财务关系可能改变,没有哪个属性时一生不变的,但标识却是永久的。

连续性:一些对象主要不是由它们的属性定义的,它们实际上表示了一条“标识线”,这条线跨越时间,而且常常经历多种不同的表示。

实体的概念: 一种贯穿整个生命周期(甚至经历多种形式)的抽象的连续性。

标识是Entity的一个微妙的、有意义的属性,我们是不能把它交给语言的自动特性来处理的。(如Java中的==标识符,内存对比)

模型必须定义出符合什么条件才算是相同的事物。

示例:
体育场座位预订,如果每张票都有一个座位号,则座位是Entity;如果票采用入场券的形式,观众可以任意挑选座位,则座位不是Entity。

考虑ID:
有时ID只是内部需要,用户可能永远不需要看到它。比如检索两个同名联系人,用户可以通过地址、公司等属性区分他们。
用户需要看到ID的场景:快递单号。

Value Object

用于描述领域的某个方面而本身没有概念标识的对象称为Value Object。我们只关心它是什么,不关心它是谁。

  • Value Object可以是其他对象的集合;
  • Value Object可以引用Entity;
  • Value Object经常作为参数在对象之间传递信息。

当我们只关心一个模型元素的属性时,应把它归类为Value Object。

我们应该使这个模型元素能够表示出其属性的意义,并为它提供相关功能。

Value Object应当是不可变的。

不要为它分配任何标识,而且不要把它设计成像Entity那么复杂。

Value Object的双向关联没有任何意义,请尽量清除Value Object之间的双向关联。

Service

Service是一系列操作,无状态,通常以动词命名。

所谓Service,它强调的是与其他对象的关系。与Entity和Value Object不同,它只是定义了能够为客户做什么。Service往往是以一个活动来命名,而不是一个Entity来命名,也就是说,它是动词而不是名词。

各层Service的区别:
service

细粒度的领域对象可能会把领域层的知识泄漏到应用层中。一种解决方法是引入领域层服务。

Service访问:可以用单例模式。

Aggregate

Aggregate(聚合)概念是为了管理领域对象的生命周期而引出的。另外两个所需的概

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值