论坛与媒体的上下文
论坛当然可以当作一个上下文,但个人感觉 图片 /视频 等媒体资源,这应该是另一个上下文。个人感觉。
论坛主要是交流的(论坛),而媒体资源应该在另一个上下文中(媒体管理)
然后,身份验证是另一个上下文。
身份验证上下文是最上游。
媒体上下文是论坛的上游。
呵呵,望各位一起讨论。
[该贴被brighthas于2014-04-12 19:58修改过]
论坛当然可以当作一个上下文,但个人感觉 图片 /视频 等媒体资源,这应该是另一个上下文。个人感觉。
论坛主要是交流的(论坛),而媒体资源应该在另一个上下文中(媒体管理)
然后,身份验证是另一个上下文。
身份验证上下文是最上游。
媒体上下文是论坛的上游。
呵呵,望各位一起讨论。
[该贴被brighthas于2014-04-12 19:58修改过]
上下文之间上下游关系视具体情况而定,可以组合。
恩恩,确实是主观和具体场景的产物,这也是其魅力所在,永远都有优化的空间。
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修改过]