使用领域驱动设计心得（1）

关于实体

实体一定要有一个id，id生成方式的设计要注意是用数据库自增长，还是自定义。数据库自增长id实现方便，但是生成时间是在数据保存时候，程序无法事先得到，因此在使用事件驱动开发的时候，无法及时的把id传给Event对象；自定义id需要自己想办法实现唯一性，可以选中的方法是UUID，但是表里必须留够32位空间。一种结合的用法是，主键使用数据库自增长id，逻辑主键使用UUID，并事先传给Event对象。物理主键只用于数据库目的：唯一识别，物理外键关联。

使用hibernate的时候，尽量不把hibernate标签写在实体中，让实体纯粹的实现业务。

关于值对象

对象优先建模为值对象，而不是实体，因为值对象应用更加方便，用之即来，用完即扔，不用维持生命周期。值对象和实体关联的时候，尽量使用单向关联，简化依赖关系。在持久化值对象的时候，一对一关系可以直接使用一个表，一对多关系的时候，可以选用子表，或者序列化整个值对象，序列化在维护表的时候比较方便，但是不利于表的属性查找。

关于资源库

资源库相对于Dao，是以实体或者聚合为中心的模型，Dao是以表为中心的，反应在代码中，就是资源库直接返回聚合，接受实体/聚合为参数。

关于领域服务

领域服务和实体、值对象一样，也是实现业务的领域模型。应该把不是由具体物理实体发出的操作，归纳到领域服务中。比如返回一个list，不属于任何一个领域对象，一种可选的做法是放在实体的static方法中，但是大规模业务使用static方法，有一种非OO的气味，因此放在领域Service中比较好。

一个可思考的业务是，请求好友的功能，当确认2个人为好友关系的时候，涉及到2个人，一个Requester，一个Accepter，好友关系确认后，2个人的状态都会发生变化。余以为confirm操作，放在任何一个人上都不合适，适合使用FriendService领域服务，操作2个实体。

转载于:https://my.oschina.net/zzg/blog/341736