领域模型实践

1 目前大部分的项目都是采用贫血模型，纵然那么多人认为不是OO的做法。也许存在即合理。

2 使用充血模型，也就是领域建模。那么实体对象要依赖仓库对象，这样在分布式环境下，如果要在网络中传输的话，会存在序列化的问题。解决办法是使用transient，或者只传输DTO，pojo。即领域对象封装一个DTO对象。

如果领域对象封装一个DTO的话，那么如果需要直接拿到DTO列表，仓库返回的应该是领域对象，还是DTO呢？方案是：直接从基础设施层拿DTO的

3 目前大部分的项目用了spring，通过依赖注入的方式来管理bean，这部分bean基本上都是单例。而领域模型中的实体，必然是不能通过spring的依赖注入来管理，因为并不是单例。

4 DDD鄙视贫血模型，认为不是OO的做法。但是POJO也是一种对象。对象虽然包括数据和行为，但是并不是每个对象都能有很丰富的行为，比如一个地板、一双拖鞋。硬要给他们行为只会变得牵强。

DDD还认为贫血模型会导致业务碎片化，不利于复用，可维护性差。

其实就算采用贫血模型也不一定会导致可维护性差，只要把可复用的，内聚性的商业逻辑代码封装好，依然可以有很强的复用性。贫血模型也一样可以有领域层，即可以复用的，核心的业务逻辑，领域层主要有服务对象构成。

DDD是否过于教条主义，就好比工程实践中，表结构的设计，不一定要严格按照范式来设计一样。

5 使用DDD的一些障碍，最直接的感受是条条框框太多。另外领域对象有可能会过于庞大，而且要依赖仓库，仓库依赖持久层。

目前想到的一个解决办法就是，使用领域层，但是领域层不包含富实体对象，只有服务对象。这样就可以无阻抗的使用spring，服务对象为spring单例bean。用服务对象来表达领域逻辑。