1.徐昊老师的代码看起来很舒服啊。就是喜欢看这种面相意图的的代码，看代码就像在看故事。 2.关于上下文，徐昊老师的这个写法我是第一次见，很有意思，长见识了。我自己一般是将上下文作为一个《应用层》到《领域层》中间的层级（乐衷于加层），用于区分不同的《领域层》。这样其实上下文就作为分包的边界在代码中体现，也算是模型与实现关联。 3.对应的仓储层不会在UserRep中收入多个上下文的操作，而是独立的BuyerRep，ReaderRep。这样做其实可以更好的分隔复杂性。但顺着老师对这些模型的定义来看，并不是很合适。因为Buyer，Reader的定义是User的角色，是一种派生。分隔包会弱化这层派生关系。可是，也不只有老师这种定义方式，如果我定义Buyer，Reader都是独立的聚合模型，与User是平级的，它们之间是聚合间平级的关系，而非 data和role的派生关系，那么在包层级上明确分隔就挺合理。拿微信来说，微信用户和微信视频号用户都是用户的派生角色吗？微信视频号用户有自己独立的用户体系，它与微信用户是两个聚合的关联关系，一个微信用户可以关联多个微信视频号用户。定义不同一切就不同。 4.我认为包结构，模块结构都算是代码的组成部分，所以也可以用来做模型与实现的关联。不知道徐昊老师怎么看？ 5.感觉还是上下文分包比上下文类模型协作风险低些。这么好看的代码（真心的，没有反义），碰上不懂的弟兄，被用错，写废的概率感觉还挺高。放到大型项目，团队协作，这真的挺让人担忧。这又涉及到一个决策点，是模型的简单重要还是模型的准确重要。我认为跳出来，看哪个对当前的团队当前的处境效益较高就哪个重要。如果硬要选一个，我选简单，可读比卓越重要（来自《实现模式》的价值观），可读要有同理心。