DDD - 概述 - (一)

本片将介绍如下内容:

　　1).DDD是什么?

　　2).怎么使用DDD?

　　3).使用DDD应该规避或者注意什么?

 

一.DDD是什么?

简言之:领域驱动设计(domain driven design),顾名思义,着重点在领域,这里的领域指的就是具体的业务领域,一个业务能够是一个领域或者多个子领域,每一个领域中包含多个子域.具体的实现更偏重于具体的业务知识,而不是技术的细节,说白了技术无关性了.

2. 咱们如何开始?

开始使用须要领域专的参与,须要领域专家对相应领域的业务分析,分析过程要注意 限界上下文:

1.核心域

　　整个业务的核心领域并划分限界上下文

2.支撑域

　　支撑其余域的域,,,,好像有点蛋疼的说法,举个栗子:假设当前系统为电商系统,其中涉及到订单这个核心模块,这个订单就能够独立成一个核心域,可是问题来了,订单会涉及到用户信息,以及用户帐户是否正常是否被冻结等权限的判断,那么这个用户的信息的内容能够独立成一个子域,可是还一个问题,不仅是订单会用到用户信息,留言\评论\等等都会用到吧,那么到这里就很明显了,这个就是所谓的支撑域了

3.通用域

　　顾名思义,通用的模块或者功能或者插件或第三方成熟的功能等等,好比,ids4.日志,中介插件,熔断重试等等

3.使用DDD应该规避或者注意什么 ?

DDD实现,另外一方面,在咱们咱们须要注意点。这些都是:

1)使用一个以数据为中心的视图建模时的问题域

一般,数据模型的第一件事是一个架构师/开发人员将开始设计。他们老是认为数据是最重要的,由于数据是咱们须要报告。若是你开始与DDD,必须改变这种心态。数据自己是没有意义的。只有逻辑给数据意义,相同的数据能够在不一样的上下文中有不一样的含义。所以,咱们必须从上下文和逻辑,而不是数据。

2)专一于实现细节等实体、值对象、服务、工厂、和存储库的核心概念

实体、值对象存储库等等没有意义,直到咱们定义了通用语言,有界的状况下,合同/制做软件的接口。若是咱们开始早期与实体等实现细节,这是个好机会,结果将是一个域周围不少服务和业务逻辑分散无处不在。

3)使用泛型和Developer-Specific术语和概念在实现应用程序

咱们不该该使用概念,好比保存、更新、删除、处理、管理、等。这些概念太技术——抽象的概念,没有具体的意义。相反,咱们必须专一于业务概念。上述的概念(即保存、更新等)不相关的业务概念。要理解这一点,我老是鼓励本身想象没有电脑客户端运行他的差事/业务(手动作特定的任务)。因此,老是想从业务/领域专家的角度来看,和给一个明确的上下文。避免通用术语,可致使不一样的含义在不一样,非特异性背景。

4)高估了数据库事务,而不是专一于业务流程或事务

在DDD,商业交易比DB更重要的事务。数据库事务是ACID(原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）),和短期运行的,而商业交易。事实上,在现实生活中,咱们不知道数据库事务,了解业务事务。例如,想象一下当你坐在餐厅,点一些食物或饮料。在订单事务,实现与否,将会有一个过程与一些异步任务不少可能的变化不一致的状态;但最后,全部状态都将一致(最终一致)。所以,与DDD,永远不要考虑数据库事务。相反,老是思考现实世界的过程,如行为和可能的结果,若是发生失败如何弥补该行为或结果。