未来产品：具体信息系统防护罩：报错

CQRS中跑在总线上那些小类型小对象啊

一直有个纠结的问题是Anycmd权限引擎中有大量的小类，Command和Event类 和Input、Output类都是小类。这些小类的唯一作用只是在总线上传递的数据的载体。很想把这些小类都去除然后使用Dictionary<string, object>去取代。但是不知道这两种方式到底哪个更好管理？哪个效率更高？这些具体的Command和Event .NET类型数据可以用来对消息（包括Command和Event）进行分类（class的本质是对人类使用了上万年的古老分类法的应用，分类的是运行时对象），然后在总线上可以通过这种基于.NET类型的分类来路由它们，基于.NET类型来登记消息类型，发布、订阅消息。

考虑是否让承载数据的小类型回老家？

然而我在Dictionary<string, Object>字典中添加个key为“MessageSubject”的项一样可以啊。而且Subject才是个更准确的词汇，对于Event来说，发布订阅时使用的词汇是Subject而不是.NET类型。
如果使用Dictionary<string, Object>取代.NET类型的话我们可以把Dictionary<string, Object>的Key提取出来持久化到数据库管理。

Anycmd权限引擎的额外收获
.NET版本的Anycmd写完后我大致明白如何把它投射成java、nodejs、golang、rust等多种版本了，不只能做到接口层使用起来是一样的，甚至能做到源代码都是相似的。

希望减少人们以后在系统的访问控制方面的纠结。anycmd设计的足够抽象，也会编码到拿来即可使用的地步，理想是人们在开发业务系统的时候再也不用书写任何访问控制逻辑，只需在上线运行前安装上权限引擎驱动的一个防护罩就万事Ok了。

具体信息系统防护罩
可以取个名字叫“具体信息系统防护罩”。
权限引擎是永远开源免费的，如果你针对某个具体业务领域配置权限引擎，你配置出那个具体领域的资源、功能、角色等数据，你初始化权限引擎，你推出的“某某信息系统防护罩”可以收费。

权限引擎官方不参与上层建设

权限引擎是底层事物，上层会有很多可能付费获得的事物：比如权限引擎管理系统（类似那个AnycmdMisSite项目，不由anycmd官方提供，任何人可以提供）、比如管理系统的UI框架、比如将权限引擎应用到具体的业务系统（帮助配置、开发）……所有的这些业务都不是官方提供的，任何人可以提供。

官方只负责构建权限引擎，如果官方提供买卖平台的话，官方只靠5%-8%的服务费维持。

困难

我搜寻过可靠权限系统设计者的言论，他们从来没有说过“业务权限”神话不可打破，只是说实现起来有困难。