码迷,mamicode.com
首页 > 其他好文 > 详细

领域驱动设计(DDD)部分核心概念的个人理解

时间:2015-05-10 18:38:27      阅读:268      评论:0      收藏:0      [点我收藏+]

标签:

  1. 领域驱动设计(DDD)是一种软件设计的思考方式。它以领域为核心,分析领域中的问题,通过建立一个领域模型来有效的解决领域中的核心的复杂问题。Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧。只有对领域的不断深入认识,才能得到一个解决领域核心问题的领域模型。如果一个应用的复杂性不是在技术方面的,而是在领域本身,即领域内的业务很复杂,那这种应用,使用领域驱动设计的价值就越大。
  2. 领域驱动开发也是一种敏捷开发过程(极限编程,XP),强调迭代开发。在迭代过程中,强调开发人员与领域专家需要保持密切的合作关系。极限编程假设我们能通过不断快速重构完善设计。所以,对开发人员的要求非常高。
  3. 领域驱动设计提出了一套核心构造块(Building Blocks,如聚合、实体、值对象、领域服务、领域工厂、仓储、领域事件,等),这些构造块是对面向对象领域建模的一些核心最佳实践的浓缩。这些构造块可以使得我们的设计更加标准、有序。
  4. 统一语言(Ubiquitous Language),是领域驱动设计中一个非常重要的概念。任何一个领域驱动设计的项目,都需要一种通用语言,一套通用的词汇。因为没有通用的语言,就没有一致的概念,沟通就会遇到障碍,最后的领域模型和软件也就无法满足领域内的真实业务需求。通用语言是领域专家和开发人员在对领域问题的沟通、需求的讨论、开发计划的制定、领域模型的设计,以及开发人员之间对领域模型的具体编码落地实现,等一系列过程中,所有人员使用的一种通用语言。话句话说,就是无论是沟通时所用的词汇、还是领域模型中的概念、还是代码中出现的类名与方法,只要是相同的意思,那就应该使用相同的词汇。可以看出,这种通用语言不是一下子就可以形成,而是在一个各方人员讨论的过程中,不断发现、明确,与精炼出来的。
  5. 领域模型是领域驱动设计的核心。统一语言中的所有关键词汇,在领域模型上应该都能找到。各方人员沟通时,都应该以领域模型为基础。通过讨论的不断深入,大家对领域的认识也会不断深入,领域模型也会不断得到完善,统一语言的词汇也会不断丰富和精准。需要特别强调的是,开发人员应该尽量保证代码实现和领域模型相绑定,时刻保持代码与模型的一致。如果不绑定,那代码就会慢慢和模型相脱节,就会出现像我们以前那样的设计文档和代码相脱节一样的问题,甚至模型还会起到误导作用。通过这样一种思路,我们确保语言、模型、代码三者紧密绑定,确保最后实现出来的软件可以准确无误的实现业务需求,并且还能让我们的软件可以快速的和业务同时演进。而不像传统的开发方式那样,分析、设计、实现三个阶段完全脱节,最后出来的软件没有很好的满足业务需求,也不能在未来很快的跟业务需求一起演进。所以,领域模型同时承载了分析的结果和设计的结果,这里的分析是指对领域内业务需求的分析,设计是指对模型的设计以及软件的设计。所以,我们的领域模型,不能只考虑业务需求,还要同时考虑软件设计的原则,是一种综合考虑的、平衡的设计结果。
  6. 领域建模的方法有很多种,我分享一下自己的一种基于场景为核心的分析方法。大概的思路是:
    • 通过与领域专家和业务需求人员沟通,找出领域中的关键业务场景;
    • 针对每个业务场景分析出有哪些场景参与者,哪些参与者以对象(聚合)的形式参与,哪些参与者以服务的形式参与;
    • 分析每个场景参与者对象的基本状态特征;
    • 分析每个场景参与者对象分别扮演什么角色参与场景,整个场景的完整交互过程是怎样的,对象在参与场景的过程中执行了哪些交互行为;
    • 分析如何记录和跟踪这一次交互行为,分析这次交互行为会产生哪些额外的信息;
    • 上面,只是简单列了一下条目,具体的描述,请参看我的另一篇文章,有详细的叙述。
  7. 关于领域、边界上下文、领域模型、统一语言之间的相互联系的理解:
    • 一个领域(Domain)会拆分为多个子领域(Sub Domain);子领域中最核心最重要的那个叫Core Domain;有时多个子领域会有相交的部分,我们称作共享内核(Shared Kernel),体现到代码上,就是同一份代码,在两个领域模型中复用;一般只有Domain比较大的时候,才会划分出Sub Domain;
    • 一个Domain相当于一个问题域,Domain拆分为Sub Domain的过程就是大问题拆分为小问题的过程;
    • 每个Sub Domain都会有一个对应的领域模型(Domain Model);
    • 每个Sub Domain必须有一个对应的Bounded Context(有边界的上下文,简称BC),一个BC可以看成是一个领域的解决方案空间;如果一个Sub Domain有对应的多个BC,那说明Sub Domain还没有划分到位,还应该在划分出更小的Sub Domain;总之,要做到一个Sub Domain只对应一个BC;Sub Domain与BC的关系应该总是尽量做到1:1;所以,不存在划分BC的说法,只有划分Domain的说法;
    • Bounded Context有两层含义:
      • Bounded,即有边界的,表示领域模型有边界;这个边界定义了模型的适用范围,以便让负责该模型的团队知道什么该在模型中实现,什么不该;
      • Context,即领域模型的产生是在某个上下文中产生的;上下文是一个动态的和环境相关的概念。比如一次头脑风暴会议大家达成了一个模型,那这次会议的讨论就是该模型的上下文;比如某本书中谈到了某个东西,那这个东西的上下文就是那本书,那个东西要有意义的前提离不开那本书这个上下文;所以,上下文是模型有意义的前提;
    • 一个解决方案需要一个团队去完成;一个团队有多个成员,需求方、领域专家、开发人员、架构师、测试人员,项目经理等;团队成员之间需要沟通,沟通用的语言就是统一语言(Ubiquitous Language);团队成员工作建模沟通时的上下文就是Bounded Context;
    • 整个解决方案最后产出的核心是领域模型;领域模型可以复用,相当于解决方案可以被复用,因为特定的领域模型解决的是某个特定的问题域;比如淘宝网有个商品中心,负责实现电子商务领域中的商品子域。后来阿里又出了个天猫,也会有商品中心,但是这两个商品中心基本是一样的问题域。所以,我们可以复用之前淘宝实现的商品中心领域模型,并复用之前淘宝商品中心的解决方案,来解决天猫的商品中心。当然,这个只是我个人的认识,一个例子。具体阿里是否是一个商品中心同时解决淘宝和天猫的业务,没具体调研过。
    • 解决方案最后落地下来就是一个系统;系统的实现需要先设计架构,比如:DDD经典四层架构、CQRS架构,洋葱架构(只是一种架构思想),等;

领域驱动设计(DDD)部分核心概念的个人理解

标签:

原文地址:http://www.cnblogs.com/netfocus/p/4492486.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!