在领域驱动设计中，最重要的就是Model Driven Development，模型驱动开发（MDD）。在编程领域有一句名言“依赖于抽象而不是依赖于具体”。这既是设计的一个原则，更是一个MDD中的过程。模型就是从具体的业务中通过思想抽象出来的。
在早期的软件开发中，一般是有着比较明确和具体的要求，行业也相对固定。这样的软件，对设计要求并不高或者说设计在其中无法起到重要的作用。正如人们的一句俗话“杀鸡焉用宰牛刀”。但这并不代表设计不重要，随着软件业务的复杂性和规模性不断成长，软件设计的重要性愈发体现出来。
而这个过程中，固定模式和相对容易与实际业务剥离的工作更利于快速引入设计，而实际情况亦也是如此。但复杂的业务和与业务有着千丝万缕的关系的部分则很难抽象设计。可是，很难不代表不可以，领域设计就是解决这种实际场景的方式，而能不能把实际精力进行高度抽象形成模型，由其来驱动进行整个型业务逻辑的开发。而一个好的模型，不但可以有更好的业务弹性和扩展性，还可以借助通用语言在不同的应用人员中间进行共同完善，并最终指导软件编码实现业务功能。
这里的一个关键点在于，以前的模型设计，模型是模型，程序设计是设计，二者基本是分割开来的，但是在MDD中，这二者的界限被模糊了，或者说将二者要有机的统一起来。这才是重点，一个模型，同步使用。
提到MDD，就不得不提到MDA，MDA，Model Driven Architecture，模型驱动架构，它是由国际对象管理组织（OMG，Object Management Group）于2001年7月提出的基于MDD形式化后的模型驱动架构。所谓驱动架构，其实就是把模型和技术分离，实现轻便可移植性、互操作性和可重用性。由于业务的代码的解耦，可以更好的适应两个层次上的扩展和自适应性。技术的迭代发展和业务的变化互无影响。
MDD的描述可以采用大家熟悉的一些建模标准（UML、MOF、XMI等）来达到可读性。
有了MDD，就会有MDF，也就是MDD Framework，模型驱动开发框架，毕竟从头搞一些东西，不断的重复造一些轮子意义不大。同时还能占领市场，高调赚钱，一举多得，搞搞框架那是最好不过的了。对MDF框架这里不做什么描述，重点还是说明MDD。
MDD的核心是什么？一定要在可控范围内严格保证模型与设计之间的一致性。在前面提到过，MDD是要保证模型的可适应性，不能像纯模型设计一样，在实际开发阶段，模型基本就没有了作用。MDD要始终保持整个模型在程序设计开发周期的可用性。那在此基础上使用一些开发工具和辅助手段是必要的。比如对一些范式的要求和工具的匹配度。
只要设计好一个实用的模型，软件开发其实就一个不断精化模型、设计和代码的统一 的迭代过程。
首先要明白MDD的一些专业术语：领域、限界上下文、关联、实体、值对象、领域服务等。这些会在后面详细解释，这里重点讲驱动流程：
1、由实际业务场景得出初步的领域和限界上下文（module），以及上下文之间的关系；
2、分析上下文，划分实体和值对象；
3、关联聚合实体、值对象，从而得到聚合的范畴和聚合根；
4、从聚合根设计仓储（资源库），同时设计如何创建实体和值对象；
5、应用模型并在实践中不断重构模型。
学习任何一种知识，一定要抓住主干，提纲挈领。以无隙入有间。领域设计，首先要搞好MDD，抽象模型的能力就是你领域设计的能力。而想有好的抽象模型的能力，除了对业务本身的领域划分（也就是边界）敏感，有着良好的领域思想理念，熟稔于模型的创建手段和方式，对技术应用有着深度的把握。才能够创建出一个优秀的领域模型。
多学习，多应用，多思考，提高思想水平。