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