听说DDD很久了，但始终停留在平时谈论中听到的一些皮毛，一直没有时间（太懒了）亲自去了解。从别人的介绍来看，DDD似乎是非常高大上的设计技术。
最近想整理一下自己的知识体系，又看到了DDD，因此，特意找时间进行了一下了解，大致如下。
首先，领域通常对应一个问题域，对软件系统而言，就是系统所要解决的问题域。领域驱动就是通过问题域驱动，进行领域模型的设计，并以领域模型为基础和核心，辅以架构设计等其他软件设计、实现方法等，最终提供可交付的软件系统。
DDD由领域分析和模型设计两个大的环节组成。
其中领域分析部分由领域理解、领域拆分、领域细化三个大的步骤组成。领域理解是理解领域的运作方式;领域拆分是指在理解领域的运作方式后，对将问题域拆分成更小的子领域，以降低问题的复杂度;领域细化则是将拆分后的子领域从场景、规则、流程等维度进行细化。
领域理解主要理解问题是什么，以及当前领域是怎么做的，所以是关键。就好比做数学应用题，如果题目没读懂，后面的计算步骤肯定是错的。说到这里，你一定会发现，这和需求分析差不多。如何才能理解领域呢？有两种办法:利用现有的领域专家或者自己成为领域专家。这两种方式都相当有难度，成为领域专家自然不必说了，利用现有领域专家其实也很难，因为往往现有领域专家不一定懂的软件设计，所以在沟通上将存在很大困难。具体如何解决这些困难在这里讲不清楚，有机会单独写文章讲。
领域拆分要按照一定的规则将大的问题域拆分成子问题域，要求边界清晰，能区分核心问题域与非核心问题域，描述子领域间的关系。领域拆分一定是建立在对领域有深刻理解的基础上的。
领域细化部分，围绕拆分后的子领域，明确其使用场景、用户、约束规则、业务流程等信息，通过细化可以对领域的关键对象如何建模有比较清晰的了解。
通过领域理解、领域拆分、领域细化，就基本上完成了领域分析的环节。接下来就进入到模型设计环节。
模型设计与软件设计过程很类似，有实体、值对象、领域事件、领域服务等模式，可以采用UML等工具进行描述。与原来的数据库驱动设计相比，模型设计是面向对象的，而不是面向关系数据库的，而且，通过领域服务、领域事件等，为模型对象增加了行为，不在是纯数据对象（贫血模型）
DDD只是软件设计的一个子集，在领域驱动设计的理念中，是最核心的子集。后面还需要有围绕这个最核心的领域模型，进行架构设计、存储设计、容量设计……
DDD是将传统的需求分析、数据库设计、软件设计等方法进行了升华、组合，并且将领域模型提高到系统核心的地位，之所以这么做，主要是为了做正确的事，可以避免架构不适应需求、过度设计等诸多问题，使得整个软件研发过程紧紧围绕问题域（实际上就是用户的需求）本身，不跑偏。
DDD设计需要分析、设计人员同时具有业务领域的专业知识，又要具有使用软件设计与实现解决问题的能力，还需要高度的抽象能力，要做好实非易事。
由于并未系统研读、实践过，文中的观点不一定正确，欢迎大家反馈不同意见。最后有几个问题，请高手们赐教:
领域分析中的领域理解、领域拆分、领域细化是否要有的输出物呢？如果要，都是哪些呢？
