在 【我有个问题】领域驱动有疑问？看这里，阿里专家为你解答！的学习活动中，通过殷浩老师的讲解和答疑，我学到了很多，对领域驱动这一方面的知识也了解了一些。
"领域驱动设计（Domain Drive Design）简称DDD，是2004年Eric Evans提出的一套软件开发的方法论，它改变了传统软件开发工程师针对数据库建模的方式，通过面向领域的思维方式，将要解决的业务概念和业务规则等内容提炼为领域知识，从而降低或隐藏业务复杂性，使系统具有更好的扩展性，以应对复杂多变的现实业务问题。"
领域驱动设计一般分为两个阶段：
- 以一种领域专家、设计人员、开发人员都能理解的“通用语言”作为相互交流的工具，在不断交流的过程中发现和挖出一些主要的领域概念，然后将这些概念设计成一个领域模型；
- 由领域模型驱动软件设计，用代码来表现该领域模型。领域需求的最初细节，在功能层面通过领域专家的讨论得出。
在领域驱动的设计中，初初我是对其切入点有些疑惑，首先我们要理解领域知识，领域知识是基础，当我们知道要设计一个怎样的系统后，大概明白解决什么问题的，但这样还不够，我们还无法开始进行实际的需求分析和模型设计。这时候就需要我们拆分领域、每个子域都得到细化。比如做一个电商平台系统，老板最经典的话就是“你仿**app做就行了”。这是不妥当的，别人的需求不一定适合自己。因此便需要使用领域驱动去设计自己的系统。通过拆分领域，把一个庞大的电商平台拆解出各部分功能，除此之外，还要分析清除每个子域的边界，明白哪些子域属于核心子域，哪些属于公共子域等，然后还要弄清楚子域之间的联系是什么。在电商系统中，通常它都包含了好几个大模块，比如：订单、购物车、商品中心等。这些都是很容易能get得到的，毕竟我们日常都在使用，受到很多的熏陶。
拆解完各个子域后，其实这时候还不行，我们还需要细化子域，如此才能进行后续的领域模型设计。这部分需要注意几点：
- 梳理领域概念：梳理出领域内我们关注的概念、概念的关系，并统一交流词汇，形成统一语言。
- 梳理业务规则：梳理出领域内我们关注的各种业务规则，DDD中叫不变性（invariants），比如唯一性规则，余额不能小于零等。
- 梳理业务场景：梳理出领域内的核心业务场景，比如电商平台中的加入购物车、提交订单、发起付款等核心业务场景。
- 梳理业务流程：梳理出领域内的关键业务流程，比如订单处理流程，退款流程等。
从这些方面理清楚我们的系统后，才能更容易解决核心需求。
