DDD-领域驱动设计

一、DDD概念介绍

　　2004年Eric Evans发表Domain-Driven Design–Tackling Complexity in the Heart of Software(领域驱动设计)简称Evans DDD。领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道。

1、什么叫DDD?

　　常见的软件开发方式是拿到产品需求后，直接考虑数据库中表应该如何设计，这种方式已经将设计与业务需求脱节，而更多的是直接考虑应该如何实现了，这有点本末倒置。而DDD是从领域(问题域)为出发点进行的设计方法。

　　领域驱动设计的核心是“领域”，从一开始就要让团队走到正确的点上。当我们组建好了团队之后，应该从哪里开始？不是UI原型设计，不是架构设计，不是设计数据库，这些事情重要却非最高优先级。

　　用正确的方法做正确的事情，运用领域驱动设计，就是要先识别问题域，进而为团队提炼达成共识的领域知识。要做到这一点，离不开团队各个角色的沟通与协作。

2、为什么要用DDD?

（1）DDD

➢核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构；

➢DDD与微服务相得益彰。

（2）微服务

➢追求业务层面的复用，设计出来的系统架构和业务一致；

➢在技术架构上，系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化的治理技术和数据。

3、团队中常见的问题

我们对客户需求的理解，存在三个方向的偏差：

    (1)从客户处了解到的需求，并非最终用户的需求；

    (2)若无有效的沟通方式，需求的理解偏差会导致结果大相径庭；

    (3)理解到的需求并没有揭示完整的领域知识，导致领域建模与设计出现认知障碍。

在团队交流中，每个人都可能成为“盲人摸象的演员”

4、通过可视化的交流达成共识

保持沟通与交流是实践DDD的前提：

    (1)只有频繁地沟通，才能就业务需求达成整个团队的共识；

    (2)只有良好的协作，才能有助于大家一起提炼领域知识，建立统一语言；

    (3)只有快速反馈，才能尽可能保证领域模型，与程序实现的一致。