要结合实际业务来讲更合理。
比如我现在有一个用户登录的业务（这个业务虽然都被大家讲烂了，但确实是最容易懂的业务了）

你得有一张表存用户数据吧，就叫 user 表吧，这个表里面有 id ，name ，password

那么你现在需要实现一个登录，那就只需要检查用户输入的 name 和 password 和数据库是否一致就可以了。
这种情况下，你就用一个 User 对象来表示这个领域模型就可以了。我一般用 Domain Object （也可以说是 Data Object ）也就是 DO 表示，对应下来就是 UserDO （ D 和 O 都大写的原因也是因为阿里巴巴的规范是这样的，所以大家一般情况下都这么来，我个人也能喜欢这种风格。如果你司统一用 Do 也可以，无所谓的，就是别一会儿全大写，一会儿大小写混着用就行了。或者你司不用 DO ，用其他的也可以，叫什么不重要，只要内部统一即可，重要的是表达什么意思）

再假设我现在有一个展示用户信息的业务，假想给一个客服（类似于管理员，但是又比真的系统管理员的权限低，就是不期望把用户密码给他看到的那种情况）
一般来说有两种做法：
第一种，你可以在序列化为 json 字符串的时候，隐藏 password 的序列化来实现；
第二种，你可以新建一个 VO （ View Object ）对象，就叫 UserVO ，然后这里面就只有 id 和 name 两个属性即可；

再假设，我现在不是直接展示到页面上，我现在是被一个业务系统调用，这个系统需要依赖于我这个登录的服务。
然后我需要提供 sdk 给这个业务系统集成，那么这个时候，就可以声明一个 DTO 对象，里面也只有 id 和 name 属性即可。

实际业务肯定不可能说只有 id ，name ，password 这么简单。

对于楼上说的一个 bean 搞定或者用 map 的，我真心不建议，过于宽泛会使得模块内聚降低（就是这个模块输入输出的可能性非常多，很容易和其他的业务模块产生不可替代性的耦合），程序本身健壮性会很差，如果时间一长，开发 A 加个属性，开发 B 加个属性，最后就会变成屎山。