由Spring应用的瑕疵谈谈DDD的概念与应用（一）

Spring 框架已经成为构建企业级 Java 应用事实上的标准了，众多的企业项目都构建在 Spring 项目及其子项目之上，特别是 Java Web 项目，很多都使用了 Spring 并且遵循着 Web、Service、Dao 这样的分层原则，下层向上层提供服务；不过Petri Kainulainen在其博客中却指出了众多 Spring Web 应用的最大瑕疵。

多数有经验的程序开发者都应该听说过DDD，并且尝试过将其应用在自己的项目中。不知你是否遇到过这样的场景：你创建了一个资源库（Repository），但一段时间之后发现这个资源库和传统的DAO越来越像了，你开始反思自己的实现方式是正确的吗？或者，你创建了一个聚合，然后发现这个聚合是如此的庞大，它为什么引用了如此多的对象，难道又是我做错了吗？

本文将会谈谈有关领域驱动设计，和领域驱动设计中使用贫血、失血和充血模型。

Spring 应用的瑕疵

现在大部分应用Spring框架的Java Web应用都相当关注单一职责原则和关注分离原则，但是在此之上却诞生了一些不太好的反模式和设计原则，比如：

• 领域模型对象只是用来存储应用的数据（领域模型使用了贫血模型这种反模式）。
• 业务逻辑位于服务层中，管理域对象的数据。
• 在服务层中，应用的每个实体对应一个服务类。

使用 Spring 框架构建应用的开发者很乐于谈论依赖注入的好处。但遗憾的是，他们很多人并没有在其应用中很好地利用其优势，如单一职责原则和关注分离原则。如果仔细看看基于 Spring 的 Web 应用，你会发现很多都是使用如下这些常见且错误的设计原则来实现的：

这类设计原则的应用非常广泛，我现在所在的Java Web项目就是使用这样的设计原则进行架构设计的，基本都是常见的三层或多层架构，他们大概是什么样的呢？

• Web层（俗称展现层吧，Presentation Layer)：接收用户输入，将数据传至服务层；
• 服务层(Service Layer，可以叫Business