Domain Object贫血vs富血(DDD)和spring roo到ruby的扯淡

很喜欢这类文章 LZ威武

不过不大明白的是。LZ已经说了。 富血模型对复杂事务的支持不大好， 但是LZ又说贫血模型适合做简单的业务。 这是不是冲突了?

我觉得“复杂的业务”很多时候都是多个领域对像之间的交互，这之间肯定会涉及事务。所以应该是贫血模型适合做复杂原业务。

很同意你的观点，貌似现在很多人认为  service和entity和DAO合并在一起，就是领域驱动了




老大说的很到位，非常同意。DDD更加关注职责划分。Domain Object有什么，Service Layer有什么，只有职责都划分清楚了，才能弄的清楚。当然DDD还有其他方面。

作为一个深度的OO粉丝，我一般用写过多少个类来计算代码量。
而那些用过程化程序员则依然用行数来计算。
一定会有很多过程化程序员来告诉我类的长度是多变的。正如行的长度也是多变的，你是否曾觉得计算字符个数更合理？
一个完美主义者写出来的类的大小一般是体型不大不小的，如果一开始不是，重构以后就是了。

下面是一些示例代码，

//以下是UI层代码
@Component
public class SomeAction {
    private SomeApp someApp;
    
    private String id;
    
    public String execute() {
        try {
            this.someApp.someBusinessMethod(this.id);
            return "success";
        } catch (SomeBusinessException e) {
            ...
            return "fail";
        }
        
    }
    
    @Autowired
    public void setSomeApp(SomeApp someApp) {
        this.someApp = someApp;
    }
    
    ...
}

//以下是应用层代码
@Component
public class SomeApp {
    private SomeRepository someRepository;
    
    public void someBusinessMethod(String id) {
        SomeEntity someEntity = this.someRepository.findById(id)
        someEntity.executeSomeBusiness();
    }

    @Autowired
    public void setSomeRepository(SomeRepository someRepository) {
        this.someRepository = someRepository;
    }
}

//以下是领域层代码
public interface SomeEntity {
    public void executeSomeBusiness();
}

public class SomeEntityImpl implements SomeEntity {
    private SomeTable someTable;
    
    private SomeRepository someRepository;
    
    public SomeEntityImpl(SomeTable someTable) {
        this.someTable = someTable;
    }
    
    public void executeSomeBusiness() {
        this.someTable.setSomeAttribute("someValue");
        ...
        
        this.someRepository.update(this);
    }
    
    @Autowired
    public void setSomeRepository(SomeRepository someRepository) {
        this.someRepository = someRepository;
    }
    
    public SomeTable getSomeTable() {
        return this.someTable;
    }
    
}

@Component
public class SomeRepository implements ApplicationContextAware {
    private SomeDao someDao;
    
    private ApplicationContext applicationContext;
    
    public SomeEntity findById(String id) {
        SomeTable someTable = this.someDao.findById(id);
        SomeEntityImpl someEntityImpl = new SomeEntityImpl(someTable);
        this.applicationContext.getAutowireCapableBeanFactory().autowireBean(someEntityImpl);
        return someEntityImpl;
    }
    
    public void update(SomeEntity someEntity) {
        SomeEntityImpl someEntityImpl = (SomeEntityImpl) someEntity;
        this.someDao.update(someEntityImpl.getSomeTable()));
    }
    
    @Autowired
    public void setSomeDao(SomeDao someDao) {
        this.someDao = someDao;
    }
    
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

//以下是基础设施层代码
@Entity
@Table(name = "some_table")
public class SomeTable {
    @Id
    private String id;
    
    ...
}

@Component
public class SomeDao extends HibernateDaoSupport{
    ...
}

分层必然会使某些代码变得麻烦，但是，我觉得当领域足够复杂的时候，是有必要牺牲的。

DDD并不会导致对事务支持不好。事务边界的划分本来就不适合于放在领域层，而应该放在上面的应用层。我听着“富血模型”这四个字就觉得很别扭，就好像富血模型和贫血模型就是两种不同的设计风格，都是正确的一样。其实要做DDD就无所谓富血，贫血，因为贫血根本就违背了面向对象和DDD，DDD从来都不贫血。我也写过好多贫血的代码，但是我现在省悟了，我要DDD，寻找领域模型，用模型驱动代码，抛弃贫血模型！

+1

可以先这样理解DDD，它是一种设计方法，与传统的面向数据库设计对立的方法。当面对一个系统的时候不应该想到的是有哪些表，先折腾数据库结构；这种设计方法只能让所有的业务逻辑更加凌乱系统模块各个都紧密的耦合在一起。DDD的做法是先进行系统的分析，识别出一些对象，Entity VO Service Repository之类的，其实就是一个为对象分配职责的过程，注意这个中间不涉及到任何数据库相关的东西，没有表结构的概念。所以重要的问题不在于用的是什么roo还是ruby之类的，重要的是你的设计是否真正的做到了不是以数据库为中心的设计，这个才是DDD真正的意义所在。

我只说一句:面向真实业务的对象...
其他的神马都是浮云

赞同，就是这个意思！

哈哈