一.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,永远不要考虑数据库事务。相反,总是思考现实世界的过程,如行为和可能的结果,如果发生失败如何弥补该行为或结果。