05｜跨越现实的障碍（中）：富含知识还是代码坏味道？

想问一下，文中的图是用什么工具画出来的？

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

把社交的上下文传递到reader里，是不是让reader耦合了社交呢？

不要user模型，直接建模reader,buyer,contact不行吗?

到了角色一步，我觉得我遇到的问题基本就解决了，因为我会把【角色】作为【聚合根】使用，可以解释为：在特定上下文中，Buyer、Reader、Contact就是聚合根，User只是一个在它们之间起到关联作用的类，只在【关联关系】相关逻辑上下文中进行使用。我觉得这样建模能够更进一步的将模型解耦。 所以我并没有很好的理解，我这样的解决方案是否还存在老师您讲的后面这些问题。

在订单上下文，聚合根不应该不应该是Order吗？在支付上下文中聚合根不应该是Payment.为啥是Buyer呢

在最后一个赠送课程的例子里，是不是可以用领域服务这概念去包装赠送的逻辑呢，因为从另一个角度看，赠送的业务逻辑，也的确是需要通过多个上下文协作完成，好像放领域服务里也合适

在实现中加入上下文依赖， 这样是不是隐藏了“必须得是friend才能赠送订阅”这个领域知识？ 毕竟从领域层已经看不到这个逻辑了， 业务逻辑相当于下放了？

老师 ddd能用在写框架上嘛 比如写个zookeper

实现随便耦合能展开讲讲吗？