上一篇我们讲了为什么需要DDD，此篇讲解一些基本概念，包含DDD的定义，使用场景和使用误区。

一、DDD定义

1. 定义描述

领域驱动设计（Domain Driven Design，DDD）是由 Eric Evans 最早提出的综合软件系统分析和设计的面向对象建模方法，如今已经发展成为了一种针对大型复杂系统的领域建模与分析方法。它完全改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过合理运用面向对象的封装、继承和多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题

上述定义引用自https://gitbook.cn/gitchat/column/5cdab7fb34b6ed1398fd8de7/topic/5cdabf6434b6ed1398fd8e5c

2. 定义理解

  • 针对领域进行建模而不是针对数据库进行建模
    • 针对数据库进行建模，然后在此基础上进行程序代码开发的方式，更多的是水平方向的拆分，比如会分为数据库层，数据访问层，业务逻辑层，展示层等。通过这种分层能达到的效果是技术的重用，比如所有和数据访问有关的技术实现代码都是在数据访问层的。
    • 而领域建模首先是进行垂直拆分，即进行业务拆分，以达到业务功能重用。而在实现拆分后的每一个业务功能时，才会考虑进行水平的分层设计或者新的菱形设计方式来达到技术的重用和隔离。
  • 主要针对的是大型复杂系统
    • 只有大型复杂系统才需要进行垂直的业务拆分，如果是简单的业务系统，不需要拆分
    • 实施DDD领域驱动设计时是有一定成本时，而此成本只会在项目后期的维护阶段才会体现出来，对于简单业务系统来说，付出的成本可能会大于后期维护的收益，所以不建议针对简单的业务系统进行DDD
  • 包含了从领域建模到代码实现的全流程的方法论
    • DDD基本概念 - 图1

  • 主要使用面向对象的语言

    • 在建立领域模型和程序设计过程中的类图，都是使用了面向对象的一些设计原则
    • 现在也发展出了一些针对函数语言的建模和实现方式，说明DDD还是有很强的包容性的

      二、DDD使用场景

  • 大型复杂的业务系统

DDD主要用于大型复杂的业务系统主要有以下原因

  1. 简单系统的业务不复杂，可以很容易沟通清楚和理解，而复杂业务系统如果不进行相应的聚集拆分的话，根本无法理解，无从下手
  2. 使用DDD是有一定成本的，这个成本体现为前期的开发速度会偏慢，而效果将在维护期间才能体现出来。对于简单业务系统来说，也是可以使用的，只是这个成本较高，没有必要，而一般复杂业务系统的维护成本是非常高的，前期一些成本换来维护期间的可维护性和可扩展性，比较划算
  • 微服务开发方式

DDD一般情况下是配合微服务开发方式使用的，因为微服务也只是一种架构思想，其主要目的也是通过业务的拆分，来减少每一个业务的复杂度，使得更容易实现，使得更容易从业务的角度进行复用。
虽然微服务要求对服务进行拆分，但是其本身并没有提供一个如何进行服务拆分的方法和工具，只能凭经验。而DDD刚好是一套从需求分析，限界上下文划分，代码架构和代码落地的完整方法和工具，两者互为补充。这也是DDD出来十多年了，只是在最近微服务大行其道后，DDD才真正火起来的原因。

三、DDD使用误区

  • 只重视设计，不重视统一语言

统一语言是DDD的最重要的概念和原则之一，如果不重视的话，则也会和以前的开发方法一样，导致需求和理解，理解和代码之间的不同步。
在DDD之前，也有很多OOD设计方法，也能设计出结构良好的类结构，并且还有很多OO设计模式可以直接用于解决特定情形下的类设计，但这些方法也是存在代码中的术语和需求术语不一致，即语言没有统一。导致每次沟通过程中都需要去理解和翻译对方的语言，并且再三确认

  • 设计完成后，实现时必须使用微服务方式

虽然前面讲到DDD主要使用于大型复杂的业务场景和微服务，但在实现时也不是必须实现为微服务的。
比如在DDD战略设计后，将需求进行了大致的拆分，形成了不同的限界上下文，但其中一些限界上下文的边界不是非常明确，或者感觉在将来可能会变动，此时可以考虑将这些限界上下文合并在一起实现。
但在实现过程中，仍然要按照限界上下文的边界进行逻辑隔离，只是限界上下文之间的调用是进程内的调用，而将来如果确定了，需要拆分为不同服务时，则只是移植出去，将进程内的调用更改为服务间的调用而已，其他不需要太大的改变就可以扩展。

  • DDD是银弹，任何项目都必须使用DDD，并且DDD能解决任何问题

既然DDD这么强大，那是不是使用DDD后就可以解决任何问题了呢？
答案是显而易见的，不是的。DDD不是银弹，不能解决所有问题。
他只是提供了一种与领域专家一起理解需求，并且对复杂业务进行拆分，逐个解决以实现完整的业务流程的方法，并且提供了在实现过程中的一些构架方式，以便代码落地实现。但在实现过程中仍然会遇到很多问题不是DDD本身能解决的，比如CAP理论的三者只能满足两个，比如服务间调用引起的分布式事务一致性等。
并且随着业务需求的变更，可能在目前认为合理的问题域拆分，限界上下文的关系，也会改变，有的需要合并为一个，有的需要进行进一步的拆分等。

四、DDD的基本流程

那如果我们想在项目中应用DDD的话，应该如何开展呢？其整体的流程是怎么样的呢？可点击传递门直达