过去一年主要在大型嵌入式系统中进行软件重构的咨询工作。对于大规模的遗留系统重构，一方面会借助领域建模帮助深入了解业务、挖掘业务本质；另一方面需要借助领域建模进行软件的再设计，指导代码的重构过程。
由于每个项目的重构效果都还不错，客户在总结时会把部分原因归结到是因为有体现业务本质的领域建模做指导。于是在客户现场就会经常被问到 “要怎么才能做好领域建模？”。大多数时候为了省时间我都直接回答“可以参考领域驱动设计（DDD）”。
然后马上就会被问到：
“领域驱动设计怎么学？”
“学习领域驱动设计有哪些推荐书籍？”
当提供一些推荐书籍后，过段时间客户又会过来问：
“领域模型和我们设计文档里的架构设计图有啥区别？”
“领域建模的核心是不是就是做好数据建模？”
“二十年前，面向对象就给出了完整的建模过程和方法了，DDD中的领域建模和面向对象建模有啥区别？”
“领域驱动设计是否一定要使用面向对象编程语言？C语言能实现领域模型吗？”
“我们当前为了安全性在做的一些软件的形式化建模工作，算是领域建模不？”
“从领域模型直接生成代码，是否可行？”
“社区里的DDD workshop都会采用的事件风暴建模方法，为什么你不用？”
OK，当所有这些问题汇集到一起，我承认我最开始的时候犯懒了！
领域驱动设计不是一个完备的软件设计过程或方法，它设立了一个目标，然后给出了部分方法。它缺失的部分，由社区里的布道者们从其它已存在的软件设计过程和方法中不断为其找素材补缺。
我赞同领域驱动设计所提倡的设计目标，但是在实践的时候却经常借用其它各种有用的软件设计方法做辅助，例如数据关系建模、面向对象分析设计、MDA、DCI方法、正交设计原则、形式化方法等等。这些方法大都是为不同目标提出来的，所以从严格的意义上来说，它们不算是领域驱动设计。但是不可否认领域驱动设计这些年被社区发展的似乎无所不含，这本也没有问题，毕竟很多新的技术方法就是通过跨界和兼容并蓄发展起来的。
但是回到解答问题上时，就不能犯懒说什么都是“领域驱动设计”，或者都不是。历史是螺旋式上升的，即使有些方法和概念又重新流行起来了，但是也肯定和之前的存在差异和改进的。通过把各种概念梳理清楚，可以帮助我们更好的学习和实践领域驱动设计。
于是趁着最近空闲，还一下自己之前犯懒欠下的债，通过这系列文章回答下被问到的和领域驱动设计有关的问题。
