Data Transfer Object与消费者服务的对应关系
由于消费者服务可能会同时与很多领域的业务对象进行交互，因此如果为每个业务领域的调用设计一个独立的DTO，这样会引发消费者服务与过多的DTO对象间产生耦合，这时候可以考虑增加一个类似DTO容器的集合类型来管理，由于DTO中的数据都是临时性的，因此这个DTO集合包括的内容可以做的大一些（，毕竟数据也都是中转而已），然后这个集合同时服务于多个消费者服务，每个消费者仅仅从这个集合中获取自己需要的一组DTO对象。演化关系如下。
1：1：1组合
这种方式适于目标服务相对数量很少，而且调用中需要用到“打包”情况不多的情况，采用一事一议的办法，为每类需要“打包”的业务领域对象包装一个DTO，客户程序调用这个DTO。（如果业务领域对象非常有限的时候，也可以采用一个DTO通过几组get()/set()分别的办法。）
1：N：N组合
当一个客户应用的需要同时使用多个Web服务的内容时（尤其是根据某些条件，有选择的使用时），可以考虑建立一系列的DTO对象，分别对应不同的业务领域对象。
1：1：N：N组合
当消费者服务需要同多个DTO交互的时候，为了简化这种耦合关系，提取一个集中的DTO集合类型，由他集中管理某个消费者服务需要的一组DTO对象，这样把消费者服务与DTO间1：M的关系，变成1：1：M。不过这由于DTO集合相对更为固定，因此消费者服务自身不需要根据DTO频繁修改。
M：1：N：N组合
对于一个企业而言，DTO集合可以不仅仅面向一个消费者服务使用，它本身的作用就是一个DTO字典，因此可以把DTO集合适当扩大，令其可以同时服务与多个不同的消费者服务。
部署设计考虑
与DTO不同，DTO Collection可以位于生产者服务端，也可以位于消费者服务端，因为它仅仅负责管理一组DTO对象的引用，考虑到组件实际执行能力的不同，消费者服务方可以仅仅保存抽象的DTO接口，而在具体业务领域对象一端保存实体DTO实现对象。
