领域驱动设计（DDD）在互联网兴起之前很流行，但是互联网的兴起一段时间不再强调领域驱动设计。在互联网处理，业务比较单薄，基本上都是CRUD就能搞定，同时，互联网业务要求快速上线，尽快抢占市场。这些特点导致领域驱动设计的有点没有办法充分的发挥。随着互联网业务的成熟和复杂话，开发人员发现添加新功能变得十分困难，再去回顾软件架构，发现已经变成了“大泥球”。这时领域驱动设计的价值就能够得以体现了。所以现在领域驱动设计开始再次流行起来。

领域驱动设计的目的就是找到行业内通用的模型，非常适合开发行业软件。领域驱动设计是由内而外的，很像修炼“内功”，从 领域模型 出发，在限界上下文中利用实体、值对象、领域服务等对业务逻辑进行建模。而 用例 驱动设计则更像是修炼“外功”，从业务用例推导系统用例，通过系统设计、概念设计、开发设计等得到最终的类。如果业务需求变更或者有新需求，领域模型的变化是内聚的、可控的，相对容易很多。

领域驱动设计用一句话来概括就是“在一个限界上下文中使用通用语言去表达业务”。为了能够将业务没有差别的反映到开发模型上，需要使用通用语言将领域专家、架构师和开发人员串联起来。这样可以保证需求可以不失真的反映到代码上。在领域驱动设计中，领域专家是必须的。他们一般在软件所要解决问题的行业浸淫多年，非常熟悉当前的业务逻辑。有了他们，我们才能够非常准确的定义出领域模型。不然是无从谈起领域驱动设计的。

在一般的开发过程中，我们的模型充斥着大量的“贫血模型”。什么是贫血模型呢？贫血模型是只有get和set方法，而没有业务逻辑的模型。在JAVA圈中，很多框架通过反射的方式初始化对象，所以要求必须有相应的get和set方法。从而导致很多人会认为模型就是带有一堆get和set方法而没有业务逻辑的对象。曾经有同事针对“ MVC ”提了个问题，MVC中的M是指“模型”，可以模型只是带有数据的对象的而已，怎么会把这种对象跟V和C相提并论，感觉不到模型存在的意义。其实是贫血模型使他对模型产生的误解，认为贫血模型就是所谓的“模型”。贫血模型有什么缺点呢？由于贫血模型不带有业务逻辑，导致业务逻辑都分散到使用模型的应用层了，多个模型的业务逻辑在应用层交织在一起，导致了“大泥球”，对以后需求的变更和新需求的添加造成了阻碍。

领域驱动设计的目的就是建立能够反映业务的模型，模型的业务逻辑内聚，可复用性强。