领域驱动设计（DDD）对开发者来说是面向对象设计的自然进化
总的来说DDD包括两个部分：
- 分析部分
分析部分通常是由开发人员去和领域专家沟通业务知识，但是开发人员和领域专家是有代沟的，
为了简化沟通成本，这时统一语言出场，统一语言是项目各方共同使用的词汇表，
在沟通业务知识，又或者叫沟通需求阶段，开发人员需要不断的完善这个词汇表，随着对需求的深入了解，
你发现某些名词存在多重含义，这种情况一般预示着多个子领域的出现,
(边界上下文)Bounded Context是DDD用来指代独立领域区域的术语，有一个子领域就有一个边界上下文,
边界上下文之间通常相互关联，这种关联关系在DDD里叫做上下文映射，它为正被设计的系统提供一个全面视图，
DDD里存在以下五种关联关系（防腐层，从属，客户供应商，搭档以及共享内核）。
- 策略部分
一旦分析部分结束，分析部分就可以产出多个边界上下文之间的映射关系（即上下文映射），有了这个系统的全局视图，
我们就可以为每个边界上下文确定合适的架构，是的策略部分的任务就是评估各种架构方案以及为每个边界上下文选择架构，
比如是使用web form ,asp.net mvc 还是分层的领域架构 又或者是简单的CRUD，
这里有一个通用的指导原则就是你要写的软件的使用期限，就是说如果你只是做一个辅助工具，而且只用一次，
那么你真的没有必要把他复杂化，相反如果你要做一个淘宝系统，那么还是考虑下DDD吧。