嘎嘎
这里面柔和了RBAC角色权限系统 Restful接口 以及上下文共享内核。其中RBAC属于业务设计，如果共享内核不是用户身份系统，是其他复杂的业务，那么就可能要进行实体或值对象了，RBAC类似一种实体和值对象设计，都是属于业务设计。
嘎嘎。
我再理顺一下啊，那里不对的话，各位和banq指教指教。
也就是说domain领域内是只能调用自身内部的东东，而外部只能通过service服务间接的“调用”，但又不准确，领域层内部还是认为调用这个服务而已，至于实现这个服务的impl，它可不知道也不想知道。
另一个层面，即便下游的系统“需要”配置上游的身份，这个也是应用层面的，这个应用层面的实现可能不只一种，比如 应用层代码： ebookdomain.on(xxxEvent,回调) ，回调函数可能用rest或发送 command 命令给 身份系统。而这个是ebook领域上下文内不知道的。
嘎嘎，各位认为那里不妥，指教指教。。。
下游上下文 listen user ，同步它的数据。
下游翻译成 本地上下文自身的 entity。
[该贴被brighthas于2014-04-14 17:53修改过]
2014-04-14 16:31 "@brighthas"的内容
说domain领域内是只能调用自身内部的东东，而外部只能通过service服务间接的“调用”，但又不准确，领域层内部还是认为调用这个服务而已，至于实现这个服务的impl，它可不知道也不想知道 ...
注意服务和RESTful服务是有本质区别的，服务可以在一个模块或一个VM内直接通过调用方法实现，也可以在机器之间通过端口以文本JSON 方式调用RESTful服务，后者是松耦合的，当然，基于消息的事件则更加耦合，连RESTful服务在哪个IP哪个端口都不必知道。
上下文之间调用应该使用后两者。
那啥，我为了不想开发完整的身份系统，我共享个user内核方式，你看咋样啊？
也就是从完美的 角色身份系统 ， 为了开发周期，退而求其次 用这种方式，目的说白了是各个系统都有个共享 user id。