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

浅析DDD——领域驱动设计的理解我觉得领域驱动设计概念的提出,是为了更清晰的区分边界。这里的边界包括业务边界和功能的边界,每个边界都包含具体的领域对象,当业务

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

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