架构师篇 DDD领域驱动设计篇-编程知识

架构师篇 DDD领域驱动设计篇

一 DDD领域驱动设计

1.1 领域驱动设计

领域驱动设计(英文：Domain-Driven Design，缩写DDD)是一种模型驱动设计的方法，领域驱动设计常以战略设计与战术设计来将整个领域展现的淋漓尽致，其作用范围既面向业务也面向技术。从战略角度(个人更喜欢称其为上帝视角)去规划系统、划分领域。而从战术角度则从技术层面来指导我们该如何去设计。

功能作用：

1.通过模型直接反映软件的结构；2.以模型为基础形成团队的统一语言；3.把模型作为精粹的知识用于传递。

领域驱动设计的核心在于领域建模，架构师的水平高低在很大程度上也体现在领域建模水平上。

1.2 mvc架构

对于业务逻辑不复杂的软件开发，MVC是简单高效的方法。但是随着业务逻辑愈来愈复杂，MVC会开始力不从心。主要体现在这几个方面：

1.MVC模式仅仅反应了软件层面的架构，它不包含业务语言，无法使用该设计直接和业务对话。

2.MVC模式天然切割了数据和行为，然后用数据库实现数据，用服务实现行为，容易造成需求的首尾分离。

3.缺乏明确的边界划分，至少在顶层设计层面没有边界划分的规范要求，更多地是靠技术负责人根据经验进行划分，大规模团队协作容易出现职责不清晰、分工不明确。

1.3 DDD的作用*

1.统一语言：

团队(业务方、产品、设计、技术等)在一个限定的上下文中有意识地形成对事物统一的描述，从而形成统一的概念(模型)。统一语言用于需求文档、PRD文档、系统分析文档、代码以及日常沟通中，统一的概念和术语可以极大地提升沟通效率和工作效率。

2.面向业务建模：

领域模型和数据模型分离，业务复杂度和技术复杂度分离。DDD聚焦于领域模型，将技术实现细节从模型中剥离出来，能够更好地降低业务和技术的耦合度。

3.边界清晰的设计方法：

通过对需求的识别及分类，划分出领域、子域和限界上下文，进而指导团队成员分工协作，从而做到将复杂的问题分而治之地解决。

4.业务领域的知识沉淀：

通过模型与软件实现关联，统一语言与模型关联，反复论证和提炼模型，使得模型与业务的真实世界保持一致，从而促使业务知识通过模型得以传递和沉淀，https://zhuanlan.zhihu.com/p/641295531

1.4 领域通用语言

需要确保团队使用的语言在所有的交流形式中看上去都是一致的，这种语言被称为“通用语言（Ubiquitous Language）”。通用语言应该在建模过程中广泛尝试以推动软件专家和领域专家之间的沟通，从而发现要在模型中使用的主要的领域概念。

1.5 DDD笔记总结

1.5.1 DDD的作用

1.ddd是领域设计：ddd是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

Ddd不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。

概述：不是一种架构，而是一种架构方法论，是一种拆解业务，划分业务、确定业务边界的方法，是一种领域设计思想。核心思想是领域模型，避免业务逻辑的复杂度与技术实现的复杂度混淆在一起。如在不同场景中，我们对同一个事物的称呼也有较大差异。例如，商品、货物；同样一个东西，在交易领域叫做商品，在物流领域叫做货物。

2.ddd的范围：

战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。

战术设计从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根，实体，值对象，领域服务，应用服务和资源库等代码逻辑的设计和实现。

3.闲谈吹牛格局

DDD思想精髓值得软件工程师以及架构师们领会，即：

1.直接面向业务进行领域建模，将业务知识沉淀到领域模型中。业务知识的沉淀不是一蹴而就，应该反复提炼，持续演进；为了让演进提炼的过程高效顺畅，团队使用统一语言来沟通、描述需求和设计方案。

2.高内聚、低耦合是应对软件复杂度的不二法则。领域、子域、限界上下文、聚合都是为这条宗旨服务的工具。

3.深刻理解业务，洞察问题本质才是一个架构师最核心的能力体现。寻找领域模型，提取统一语言，做分层与隔离。