DDD领域驱动设计


基本概念:

  领域驱动设计(简称 ddd)概念来源于2004年著名建模专家eric evans发表的他最具影响力的书籍:《domain-driven design –tackling complexity in the heart of software》(中文译名:领域驱动设计—软件核心复杂性应对之道)一书。,书中提出了“领域驱动设计(简称 ddd)”的概念。
  
       领域驱动设计告诉我们,在通过软件实现一个业务系统时,建立一个领域模型是非常重要和必要的,因为领域模型具有以下特点:

     1.   领域模型是对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质;领域模型是有边界的,只反应了我们在领域内所关注的部分;

     2.   领域模型只反映业务,和任何技术实现无关;领域模型不仅能反映领域中的一些实体概念,如货物,书本,应聘记录,地址,等;还能反映领域中的一些过程概念,如资金转账,等;

     3.   领域模型确保了我们的软件的业务逻辑都在一个模型中,都在一个地方;这样对提高软件的可维护性,业务可理解性以及可重用性方面都有很好的帮助;

     4.   领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造;

     5.  领域模型贯穿软件分析、设计,以及开发的整个过程;领域专家、设计人员、开发人员通过领域模型进行交流,彼此共享知识与信息;因为大家面向的都是同一个模型,所以可以防止需求走样,可以让软件设计开发人员做出来的软件真正满足需求;

     6.  要建立正确的领域模型并不简单,需要领域专家、设计、开发人员积极沟通共同努力,然后才能使大家对领域的认识不断深入,从而不断细化和完善领域模型;

     7.  为了让领域模型看的见,我们需要用一些方法来表示它;图是表达领域模型最常用的方式,但不是唯一的表达方式,代码或文字描述也能表达领域模型;

     8.  领域模型是整个软件的核心,是软件中最有价值和最具竞争力的部分;设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化;

实体 Entities

实体是一个具有唯一身份标识的对象,并且可以在相当长的一段时间内持续地变化。我们可以对实体做多次修改,一个实体对象可能和它先前的对象大不相同,但拥有相同的身份标识(identity),依然是同一个实体。对这些对象而言,重要的不是其属性,而是其延续性和标识,我们把这样的对象称为实体。



四种模型定义 :

失血模型 :模型仅仅包含数据的定义和getter/setter方法,业务逻辑和应用逻辑都放到服务层中,这种类在java中叫做POJO类。

贫血模型 :贫血模型中包含了一些业务逻辑,但是不包含依赖持久层的业务逻辑,这部分会放到服务层。

充血模型 :充血模型包含了所有的业务逻辑,包括依赖于持久层的业务逻辑,不仅是多个业务属性的载体,也是操作和行为的载体。

胀血模型 : 胀血模型就是把和业务不相关的其他应用逻辑(比如授权,事务等)都放到领域模型中。可以认为是另外一种的失血模型,因为服务层service消失了,领域层干了服务层的事,到头来还是什么都没变。

DDD中的实体,通常属于充血模型。

值对象 Value Object

 值对象的定义是:描述事物的对象;

  关于实体与值对象的一个例子:比如员工信息的属性,如住址,电话号码都可以改变;然而,同一个员工的实体的标识将保持不变。因此,一个实体的基本概念是一个持续抽象的生命,可以变化不同的状态和情形,但总是有相同的标识。

聚合及聚合根

        聚合是用来定义领域对象所有权和边界的领域模式。聚合的作用是帮助简化模型对象间的关系。聚合,它通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚,并避免了错综复杂的难以维护的对象关系网的形成。聚合定义了一组具有内聚关系的相关对象的集合,我们把聚合看作是一个修改数据的单元。       

        一个聚合是一组相关的被视为整体的对象。每个聚合都有一个根对象(聚合根实体),从外部访问只能通过这个对象。根实体对象有组成聚合所有对象的引用,但是外部对象只能引用根对象实体。

一般来说,中台建设会站在企业高度,所以我们将问题空间定位在全企业的业务域。当我们从DDD的视角来进行领域分析时,我们会根据核心业务环节或者功能聚合边界以及领域经验等多个维度,完成从领域到子域的细分。并根据企业发展战略来分析,以确定子域到底是通用子域还是核心子域。

而当我们从中台建设视角出发,将不同的业务板块细分为通用中台和核心中台时,从下图中我们就可以发现,中台一般会跟DDD的某一个子域对应,所以我们可以认为:“中台本质上就是按照DDD方法从企业业务领域细分出来的某个子域”。

为了避免同样的概念或语义在不同的上下文环境中产生歧义,DDD 在战略设计上提出了“限界上下文”这个概念,用来确定语义所在的领域边界。这里可以将限界上下文拆解为两个词:限界和上下文。限界就是领域的边界,而上下文则是语义环境。通过领域的限界上下文,我们就可以在统一的领域边界内用统一的语言进行交流。

根据业务bizCode 串联各域

 

下单

 ​​​​​​​​​​​​​​DDD领域驱动设计_第1张图片

履约

DDD领域驱动设计_第2张图片

 

售后

 DDD领域驱动设计_第3张图片

 

 

你可能感兴趣的:(我想和你去一个地方,大数据)