之前就“驱动”、“领域驱动”这些主题做了一些讨论，现在看看作为一种架构设计的驱动技术，“领域驱动”有何特点。
乍看之下，领域驱动与特征驱动有些关系。那我们就从跟特征驱动的区别说起。
首先，两者的起点是不一样的 -
- 一般来说，特征驱动中所谈的特征，也可以说是“需求”。讲的是需要实现的系统的特征，而不是业务问题本身的特征，需求已经是产品同学（或业务分析同学）的设计结果，体现系统的边界和职责。它已经是对业务问题的部分应对了。
- 领域驱动所做的，是对业务问题的直接建模与拆分。更多的讲的是业务本身的特征特点，没有涉及到系统，也没有涉及到的系统的边界与职责。
- 所以两者的起点是不同的。可以说，一个从经过设计的需求开始，一个从未经设计的问题本身开始。
其次，通常来讲，特征包括功能、质量、约束。领域驱动几乎完全没涉及到质量、约束方面的特征。功能方面，如前所述，也不是直接对应。
作为一种驱动技术，我们按照对驱动者的一般要求，来看一下领域驱动的能力。
- 首先看拆分问题。DDD维护一个分析模型到设计模型的机械映射，只要拆分分析模型，就完成了问题的拆分。分析模型本身有结构，所以拆分是比较容易的。但是，不论是分析模型，还是其映射而成的设计模型，都很难直接验证。一般只有通过对模型的使用，才能间接验证。
- 其次看推动问题的解决，由于机械映射的存在，基本上完成了分析模型，就完成了设计模型。大部分的工作，都集中在分析模型方面。而分析模型的完成程度，可以说是很难衡量和可视化的。
如上特点，决定了使用领域驱动时的一些注意事项
- 一个系统的架构设计中不能只有领域驱动。领域驱动考虑的只是问题的一部分或者说一个方面。其他方面需要其他驱动技术来考虑。比较典型的是质量方面，比如性能、可用性等。
- 需要通过对模型的使用来间接验证领域驱动的设计。比如通过功能/UseCase来验证，看这个模型上面能否满足功能的逻辑。而功能/UseCase，通常是依赖于对系统特征的定义。
领域驱动与特征驱动，常常伴生。领域驱动在时间、空间上的广度视野，与特征驱动在细节、具体层面的管理能力，可以相互补充。