对，这样描述就很清楚了...

。。。 还得讨论，感觉心里不踏实，看看banq大哥有啥高论。我再嘎嘎两下，看看banq出来不。

嘎嘎

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

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

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

嘎嘎。

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

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

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

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

如果为了提高开发效率，因为开发完整的针对角色权限的system太复杂。我共享 “user”内核，如何呢？

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

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

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

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

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

恩，谢banq大大。

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

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