领域驱动设计（DDD）的概念源于2004年著名建模专家Eric Evans发表的书籍: 《Domain-Driven Design –Tackling Complexity in the Heart of Software》（中文译名：领域驱动设计—软件核心复杂性应对之道），池建 强在2011年发表的一篇文章《领域驱动设计和实践》中是这样形容DDD的：
领域驱动设计事实上是针对OOAD的一个扩展和延伸，DDD基于面向对象分析与 设计技术，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分 。
本文主要介绍为什么我们在恒拓开源内部推广DDD，我们如何通过开发DDDLib 和Koala等工具来完善这一过程，推广过程中遇到了哪些问题，以及我们如何解决 这一问题。
为什么选择DDD
传统的模式的最大优点在于开发人员非常熟悉，开发成本低，但它也有一些问 题：
采用DDD开发模式之前，传统的开发模型是最流行的Model-Dao-Service-UI开 发模型，通常是基于事务脚本（Transaction Script）和表模块（Table Module ）模式的实现，这种模式通常是先设计表，再建模，实现容易依赖特定的表的一 些特性，如存储过程。基于表的设计模式容易带来以下几个问题：
业务建模完全是表的复制，无法真实反映业务
核心业务分散在各个地方，非常危险，修改扩展难，且难以阅读
这种开发模式适合一些需求小，后续维护扩展需求小的中小型项目，但在大型 企业级系统或产品，扩展维护或需求变量非常多的情况下，缺点也非常明显。
相对而言，DDD则有以下四点好处：
面向对象，模型真实反映业务现实：使用DDD领域驱动设计，模型通常是业务 的真实反映，业务集中在领域而不是分散在各service中，有利于对业务的理解。
使用领域统一建模语言：有利于业务沟通与建模： DDD倡导先对业务建模，而 非关注表或脚本的设计；在建模过程中，由于领域本身是对真实业务的反映与建 模，因此与业务专家更容易沟通，打破技术与业务的沟通隔阂。
可重用性高：DDD中，领域层为核心，每个领域对象都是一个相对完整的内聚 的业务对象描述，所以可以形成直接的复用。基于领域建模的设计，并不会依赖 特定的数据库及特性，模型是可以完全重用且没有技术上的冲突。
业务越复杂，DDD的优势越明显：领域模型采用OO设计，通过将职责分配到相 应的模型对象或Service，可以很好的组织业务逻辑，当业务变得复杂时，领域模 型显出巨大的优势。