浅析DDD——领域驱动设计的理解

  • 我觉得领域驱动设计概念的提出，是为了更清晰的区分边界。这里的边界包括业务边界和功能的边界，每个边界都包含具体的领域对象，当业务和功能的领域对象一一对应上之后，业务的变化就能很清晰的反馈到功能实现上，到这里就做到了业务架构驱动了技术架构的发展。
  • DDD是一个概念性很强的东西，理解起来有点绕。为了方便对这一概念的理解，DDD引入了一些专有的词汇，我用订单系统配合解释说明一下：
  • 领域：用来划分区域范围，一个领域对应着一系列问题（例如订单系统本身就可以作为一个领域，用来解决支付问题）
  • 子域：领域的进一步拆分，将领域拆分成更细的子域（例如订单系统可以拆分成订单、支付、积分、退款、优惠等），子域按照职责可以划分为核心域、共享域、支撑域：
  • 核心域：一般是项目的亮点功能或核心重要功能，核心域一般需要投入更多的资源。核心域在不同的环境中的定义可能会有所区别（例如对于BI分析系统来说订单是核心域，对于策略系统来说优惠是核心域）
  • 共享域：指的是多个子域共享的域（例如权限认证、用户登陆等）
  • 支撑域：非关键的域（例如字典、展示效果计算等）
  • 语义：指的是领域对象的叫法。这个概念我详细说明一下，一个项目的落地需要很多角色，包括产品经理、项目经理、架构师、研发、测试、运维、运营等角色，每一个角色对一个事物都有自己的角度和认知。不同角色之间对功能产品的交流会花费更多的精力，但还是有可能造成信息传递的不一致。语义就是为了解决这个问题而提出的，首先各个角色坐在一起进行产品的沟通，沟通过程中会划分出不同的领域，然后从领域中提取领域对象并对其进行命名，大家一同定义出来的对象名称，就会作为标准的语义存在。
  • 边界：不考虑功能拆分粒度对实际业务的影响，一般一个边界就是一个单独的功能对外进行服务。这里有一个特殊点：定义语意的前提是边界明确。这个概念很好理解，例如一部手机，它出工厂之后的语义是产品、它在运输车上的语义是货物。