Entity/VO/DTO/Domain Object/Biz Object等名词的含义

一、VO和DTO
VO:  Value Object
DTO: Data Transfer Object
个人理解VO和DTO是类似的东西，原则上VO和DTO只有Public Fields，主要用于进程之间数据传递的问题，VO和DTO不会传递到表示层，在业务层就会被吸收。但看到很多人在建立VO和DTO时，也含有Setter,Getter属性和一些其它的辅助方法，这也无可厚非，我自己也不能确定这对不对。望大家给出意见。

二、Entity和Domain Object
Entity和Domain Object应该是类似的东西，我觉得这两者概念上可能与Biz Object(Business Object)有所不同，但我看到网上很多文档都把他们当成类似的东西。
Entity和Domain Object除了有Setter,Getter属性外，还有仅仅属于自己的一些专有(special)方法,如CRUD及其他专有方法，和有一些Services接口，并不涉及Domain Object与Domain Object之间关系的一些方法。也就是说Domain Object负责数据持久化，这可以由其IDataServices接口来实现。Entity和Domain Object更强调具体是哪一个对象，或者说是实例化的Entity和Domain Object对象。
如果用Domain Object来设计程序，不自觉地就会遵守一些重构策略(如Divergent Change、Shotgun Surgery、Switch Statements等，具体可以看Rickie的blog)，我们知道Domain Driven Design这本书出现在Refactoring这本书之后，看来也是Martin Fowler对Refactoring进一步总结、升华的结果。用Domain Object来设计程序，降低了类之间的耦合，可以不自觉地达到Refactoring结果。看来出现Refactoring后，Domain Object的出现只是时间的问题。

idior的O/R Mapping 基本概念和一个困扰我长时间的问题也谈到了Entity和Domain Object

三、Biz Object
个人理解Biz Object更加专注于业务实现，主要强调业务类之间的关系。这也是它与Entity或Domain Object的不同之处。
在具体的程序中有时还会有Manager类，用于管理Biz Object和作为Biz Object的Facade。

我一直没有成型的架构，下一步抽时间看看Domain Model 探索和EDRA，我更觉得架构不用通用，可以根据一些典型的业务建立合适的架构，更希望大家能给出好的架构。