wilsonp
2014-04-14 12:01
对,这样描述就很清楚了...

brighthas
2014-04-14 12:03
。。。 还得讨论,感觉心里不踏实,看看banq大哥有啥高论。我再嘎嘎两下,看看banq出来不。

嘎嘎

banq
2014-04-14 15:18
你描述的基本正确,身份和业务系统之间通过Restful服务接口和角色配置数据进行交互,业务系统只要调用身份的服务接口,传入两个参数,当前操作的用户的角色和当前操作的名称,后者可以是当前Java方法method的名称都可以,身份系统接受到这两个数据,和之前管理员的配置进行核对,是否符合,如果符合表示该角色可以操作该Java方法。

这里面柔和了RBAC角色权限系统 Restful接口 以及上下文共享内核。其中RBAC属于业务设计,如果共享内核不是用户身份系统,是其他复杂的业务,那么就可能要进行实体或值对象了,RBAC类似一种实体和值对象设计,都是属于业务设计。

brighthas
2014-04-14 16:31
very 感谢 banq,其实banq总是被人误会说话含糊,其实我这里给banq大叔正一下名,是因为banq大叔宏观的格局有些人不理解,所以才感觉含糊。

嘎嘎。

我再理顺一下啊,那里不对的话,各位和banq指教指教。

也就是说domain领域内是只能调用自身内部的东东,而外部只能通过service服务间接的“调用”,但又不准确,领域层内部还是认为调用这个服务而已,至于实现这个服务的impl,它可不知道也不想知道。

另一个层面,即便下游的系统“需要”配置上游的身份,这个也是应用层面的,这个应用层面的实现可能不只一种,比如 应用层代码: ebookdomain.on(xxxEvent,回调) ,回调函数可能用rest或发送 command 命令给 身份系统。而这个是ebook领域上下文内不知道的。

嘎嘎,各位认为那里不妥,指教指教。。。

brighthas
2014-04-14 17:51
如果为了提高开发效率,因为开发完整的针对角色权限的system太复杂。我共享 “user”内核,如何呢?

下游上下文 listen user ,同步它的数据。

下游翻译成 本地上下文自身的 entity。

[该贴被brighthas于2014-04-14 17:53修改过]

banq
2014-04-14 18:02
2014-04-14 16:31 "@brighthas"的内容
说domain领域内是只能调用自身内部的东东,而外部只能通过service服务间接的“调用”,但又不准确,领域层内部还是认为调用这个服务而已,至于实现这个服务的impl,它可不知道也不想知道 ...

注意服务和RESTful服务是有本质区别的,服务可以在一个模块或一个VM内直接通过调用方法实现,也可以在机器之间通过端口以文本JSON 方式调用RESTful服务,后者是松耦合的,当然,基于消息的事件则更加耦合,连RESTful服务在哪个IP哪个端口都不必知道。

上下文之间调用应该使用后两者。

brighthas
2014-04-14 18:13
恩,谢banq大大。

那啥,我为了不想开发完整的身份系统,我共享个user内核方式,你看咋样啊?

也就是从完美的 角色身份系统 , 为了开发周期,退而求其次 用这种方式,目的说白了是各个系统都有个共享 user id。

猜你喜欢
2Go 上一页 1 2