论坛与媒体的上下文

上下文之间上下游关系视具体情况而定，可以组合。

恩恩，确实是主观和具体场景的产物，这也是其魅力所在，永远都有优化的空间。

banq大哥，下游可以操作上游的领域方法吗。

这其实应该是上下文之间的关系，可以是映射，也可以是通过异步事件进行通讯，采取直接调用对象的方法方式是不行的，跨越上下文边界发生耦合了。

上下文是显式的，是人脑思考的产物，因此是有边界的，正如量子的波粒二象性，你观察时它是一颗颗有边界的粒子，而不观察时，其实它是连续的波，隐式的世界是连续的，正如连续的线是由单个点组成。

当我们用上下文这个显式方法去分析隐式客观世界连续的线时，如何划分边界就很重要，这个划分不能像拿把刀，想怎么切就怎么切，得通过聚合的发现来自然形成，比如大雨打在莲花叶上，自然会缩成一个个有边界的水摊，这是自然聚合而成的上下文边界。

恩，banq说的很明白！

下游上游在一个物理环境中，下游可以通过query查询上游么？但不调用上游领域对象方法。

我的几个上下文都有一个query对象，是cqrs的query部分。

领域模型只适合CQRS的Command这条路线，属于这个边界如下图，Query属于与Command并列的另外一个边界。

Command(DDD(上下文))

恩恩。

下游通过rest可以访问上游，上游是开放主机，如果在一个物理容器，可以把直接访问上游的query么？

也就是说用query形式代替rest，如果是两个主机，也可切换到rest。

还有个问题，就是你介绍的 《实现领域驱动设计》这本书，里面是推荐用下游通过rest访问上游 身份管理上下文 ，感觉适合他举的例子。

如果是 5个上下文边界，这几个边界的身份验证逻辑比较“特殊”，不适合单一“角色”判断。是否可以使用共享内核呢？

就是把“身份管理界面”改成“用户管理”的共享内核方式。比如电子书系统的读者用户，和论坛的用户和协作系统，里面的协作系统和论坛的用户可以用身份角色来验证权限，但电子书读者需要需要判断 “是否有权读某本书”，这个就不适合用角色判断了。

banq大哥指点指点

这种情况是不是 “共享（用户）内核”比较靠谱和实际些？

这里的“共享（用户）内核”指的是用户实体在所有的上下文中都存在的吗？还是指其他意思？

我觉得是这样的啊，也是上游，然后映射到下游领域对象。

共享用户内核，其实类似专门的身份认证系统，实际中通过引入RBAC，使用角色作为具体业务系统(上下文)和身份系统的桥梁，或者称为映射桥梁，只要业务系统告诉身份系统的服务自己是什么角色，身份系统就告知其这个角色对某个操作是否有权限。

也就是说，上游的“它” 知道具体业务系统的细节？否则怎么知道是否有权限呢？
[该贴被brighthas于2014-04-14 11:42修改过]

我知道了有些，banq大哥，你看看我说的靠谱不？下面是我的场景描述：走一个。。。

身份系统上下文中当然不知道电子书内部的细则，而是由admin也就是我（嘎嘎）去进入到身份系统中去“配置的”，这个“配置” banq大哥你懂得， 嘎嘎，不说太明了，嘎嘎。

也就是说配置只关心Who、What、How。

－－－－－－－－－－－－－－
还有个问题，即便我可以配置授权，那有人购买了“电子书”肯定要把这个 user id 授权为“可阅读”的角色，必然要“配置”身份系统，而这个时候的“配置”显然是由 电子书系统（上下文发出的事件）。

而这个事件由一个监听器得到了，它通过一个应用层service 操作－－－》身份系统的“配置”。

我是这么理解的。

[该贴被brighthas于2014-04-14 12:00修改过]