在读大学的时候就听过“领域驱动”这个词，但到工作几年后还是一直半解。在这过程中看过《领域驱动设计》这本书，也在开发中有意识的使用该理论和概念。或许把自己对领域驱动的理解写出来后，才会对它有进一步的感悟。
统一语言
领域驱动里强调“一个团队，一种语言“，这里的语言并不是指编程语言，而是沟通交流时双方都能理解对方意图的手段。比如约定专业术语或者通过 UML 图等手段扫除交流的障碍。
业务模型
敏捷开发提倡拥抱变化，这本来是件好事，但很不幸的是有时候成为不做设计的托辞。试想下是多么幸运的团队，才会出现刚好既有代码可以随需求变化而稳定的变化。如果能抽象出恰当的模型，那么至少需求变化时能减少伤筋动骨的可能。
图片来源《领域驱动设计 软件核心复杂性应对之道》
领域愿景
软件开发中的各种需求之间有不同的契合度，比如实现了某个需求那可能其它需求将很难实现，故导致在可承受的成本和代价下只能实现所有想要需求的子集。这样通过恰当的愿景可以约束人的欲望，尽量把资源投入到预期产生价值的需求上，或许这样反而能获取更多客户的青睐。
图片来源《软件开发本质论：追求简约、体现价值、逐步构建》
子域划分
高耦合的代码是开发者的焦油坑，代码间错综复杂的关系将会把有问题代码的负面影响扩大到闻者避而远之。那么依据实际情况划定子域范围并且各子域间尽量只保持必要的联系，则有问题代码的负面影响将会被大大削弱。
重构目标
写了很多年代码清楚百密也有疏忽，并且实际情况下也没有条件对所有代码都投入大量的时间和精力，这样就出现有问题的代码夹杂在良好代码里。同时随着客户的需求变化等原因，原先表现良好的代码表现得越来越差。通过上面的现象引申出代码“时效性”这个概念，在软件产品生命周期过程中会不断有代码被判定“过期”应当被替换。
图片来源《软件开发本质论：追求简约、体现价值、逐步构建》
