12 | 领域建模：如何用事件风暴构建领域模型？

作者回复: 是这个意思。DDD领域建模优先，领域建模的时基本不考虑数据模型和数据库实现。在微服务具体落地的时候才考虑数据实体的设计。

作者回复: 根据单一职责的设计原则，用户上下文应该只负责用户相关的管理职能。商品的收藏虽然跟用户关联，但应该属于商品上下文，商品上下文内可能会有商品目录聚合和商品收藏聚合等。在设计时，你可以将收藏的商品与用户ID建立关联就可以了，用户ID是值对象。用户登录时，可以根据用户ID查询到匹配的商品收藏清单。

作者回复: 是这样的，其实DDD刚出来的时候并不是为微服务设计的。你可以根据自己得需要，做好领域建模和划分好边界，刚开始并不一定要拆的很细，等真正需要拆分的时候再拆，用DDD设计的系统很容易解耦，很容易拆分出微服务来的。

作者回复: 领域建模的过程不光是建立一个领域模型，更关键的是建立团队通用语言的过程。所以需要团队成员尽早参与，后面开发和测试就会容易很多，也不会出现方向偏离。

作者回复: 这个需要根据您的业务场景来具体分析。我试着来分析一下。一般来说在用户权限体系里，会有User、Role等聚合，其中Role作为聚合根，会引用Menu实体，建立role的菜单权限体系。User和Role聚合主要用于管理用户以及角色等基础信息，比如用户的增删改查，删除Role中的菜单权限，删除Role等基本操作。 在进行用户权限配置时会有另外一个聚合UserRole，这个聚合的聚合根引用用户值对象和Role值对象，在这个聚合管理用户的角色权限配置，建立User和Role之间的关联。

作者回复: 有什么疑问，咱们可以谈讨哈。

作者回复: 你说的这个场景不是富领域模型，可能找不出聚合根，因此不适合用聚合的方式来做。但是你可以用DDD的分层架构来划分不同的服务，按照外层依赖内层服务的调用关系来开发。

作者回复: 这一块研究的还不太深入呢。后面我再研究一下。

作者回复: 领域建模的目的是为了微服务的设计，领域模型是开始，DDD是一种不同于传统设计的方法 ，先有领域模型，然后才有微服务设计，这样设计的微服务边界很清晰，而不是靠拍脑袋设计微服务。等学完后面全部DDD的内容后，你就知道其中的奥秘了。

作者回复: 事件是独立的，一些操作发生后会产生事件，事件主要用于上下游业务的数据流转和领域模型和微服务解耦，不用挂到某个实体下面。团队的管理在聚合根，聚合根的有些职能会拿出来放到工厂和仓储里面，比如聚合实体的初始化，聚合数据的持久化。解散团队的操作当然在聚合根实体。