DDD 概念理论

 

DDD 全称（Domain-Dirven Design -Tackling Company in the Heart of Software）

作者：Eric Evans

注意：DDD是为了应对复杂软件开发 不是技术概念，是业务概念--领域是领域专家（业务专家）提出来的，是非常偏义务的。

我们要做的就是，理解领域、拆分领域、细化子域

DDD是一种程序分析设计方法，不关乎具体技术实现

POP-无边界（砌墙） OOP-以对象为边界（设计师-小区）

DDD-更大的边界（总设计师）---就是领域（其实会用别的方式来表达-有大有小）和技术无关，跟业务有关。

 

理解DDD

Domain Driven Design（领域驱动设计）

通用定义：领域驱动设计事实上是：

1、针对OOAD的一个扩展和延伸，DDD面向对象分析与技术设计。

2、对技术架构进行了分层规划

3、对每个类进行了策略和类型的划分

 

Domain （领域）：领域就是问题域，用来解决某个特定问题的。

Design：设计主要指领域模型的设计：

1、项目是按照领域来做的设计，每个领域都是按照设计 来制定的

2、完成每个领域，组装起来就一定能够完成全部需求，不会偏离变形

 

常见的开发思路：需求沟通->设计数据库->搭框架->编码->测试->改需求<-改需求->维护起来很麻烦

DDD开发思路：要重视需求分析！！！，不涉及技术。

 

Driven（驱动）：

• 领域驱动领域设计---基于领域（问题域）完成领域驱动设计（各种细节）
• 领域驱动代码实现---规则定好，去写代码实现

 

DDD意义

• 以领域（问题域）为核心，基于领域来完成领域的设计（规则细化），基于领域完成代码实现，然后组装领域就能完成功能且不变形。
• 带来的：项目的开发流程和思路变化，做好需求分析。

 

DDD落地三部曲 ，理解领域、拆分领域、细化领域

理解领域

• 理解领域（业务）知识是基础，明确做啥系统，主要解决什么问题，但还需要理解业务，理解问题域。

 

拆分领域

• 拆分领域，本质上就是把大问题拆分成为小问题，然后各个击破的思路，分而治之的思想。
• 举例：电商平台，用户、订单、支付、商品、物流仓储、售后、营销积分。。。
• 拆分粒度：没有答案，问题域可大可小

 

细化领域

• 梳理领域概念：梳理出领域内我们关注的概念、概念的关系，并统一交流词汇，形成统一语言。
• 梳理业务规则：梳理出领域内我们关注的各种业务规则，DDD中叫不变性（invariants），比如唯一性规则余额不能小于零。
• 梳理业务场景：梳理出领域内的核心业务场景，比如电商平台中的加入购物车、提交订单、发出付款等核心场景；
• 梳理业务流程：梳理出领域内的关键业务流程，比如订单处理流程，退款流程等。

到这里为止，依旧不关心技术。

 

DDD是什么：

• 是OOAD（Object Oriented Analysis Design，面向对象的分析和设计，面向对象分析与设计）的扩展和延伸，是一个面向对象分析和设计的技术（方法/风格）,以领域为核心。注重需求分析，还提供了一系列的分层方式、工具、方法论。

为什么要用DDD：

• 为了提供”银弹“，能解决各种复杂类型项目的开发，通过通用语言解决沟通问题；通过领域拆分来分而治之。

什么时候用DDD：

• 为了应对复杂的项目。

怎么用DDD：

• 理解领域-》拆分子领域-》细化子领域-》使用分层-工具-方法论去与驱动代码实现。

 

最后说一句：

 DDD 更偏向业务，技术人确实要弱化，需求分析很虚（靠感觉、凭借经验），对于开发人员来说，要理解，要支持。它只是设计只是整个软件设计中很小一部分。还有各种设计需要完成，例如架构设计、框架设计、数据库设计、缓存设计、框架选型......，要有一个开放的心态去理解它。