diff --git a/README.md b/README.md
index 80a84fd..e035de1 100644
--- a/README.md
+++ b/README.md
@@ -126,13 +126,13 @@ ServiceAnt 支持以下两种方式注册处理函数
 
 ### 注册委托
 
-这种注册方式已经在之前的代码片段中演示过了, 它支持两种不同输入参数的委托, 一种是显式的泛型, 还有隐式的动态类型.  
+这种注册方式已经在之前的代码片段中演示过了, 它支持两种不同输入参数的委托, 一种是显式的泛型, 还有种就是动态类型  
 
 值得一提的是，虽然我更推荐通过Ioc来注册处理函数（这样可以获得更好的可读性与可修改性以及可测试性）,  
 但在我们团队使用过程中并没有发现通过委托注册存在什么弊端，而且在你需要复用某些局部变量时, 这种方式会更好一些。  
 
 > ### 注意
-> 隐式的动态类型现在没法正确注册泛型的 Trigger 的处理函数, 因为泛型在转换名称的过程中不是单纯的类名转换
+> 动态类型参数的注册需要用到事件名称，这可能会导致无法正确注册某些泛型 Trigger 的处理函数, 因为泛型在转换名称的过程中不是单纯的类名转换
 
 ### Ioc注册
 
@@ -323,14 +323,15 @@ ServiceAnt 在触发处理函数的过程中,可能会产生某些异常,正常
 起因是这样的，我们团队在开发一个企业应用时采用了DDD，然后将我们的业务逻辑拆分为了复数个限界上下文，每个上下文低耦合高内聚的.  
 
 但无论再怎么低耦合，总会有一些高层次的交互，这些被称为“边界点”，通常在分布式部署中，我们会选择Webapi 或者 WebServie 等远程通信手段来进行交互  
-遗憾的是，我们的应用是线下的，并发量也并不需要到集群这样重量级的解决方案，所以我们使用Abp的插件加载机制为基础设施,  
-将每个上下文都实现成了一个个独立的项目模块.  
+
+遗憾的是，我们的应用是线下的，并发量也并不需要到集群这样重量级的解决方案，所以我们使用Abp的插件加载机制为基础设施, 
+将每个上下文都实现成了一个个独立的项目模块.  
 
 项目初期我们使用 Abp 提供的事件总线作为模块之间交互的方式, 但它有一个很不好的地方是, 它的事件引用必须是显式的原对象引用。    
 这也就意味着，你为了在A模块中使用B模块发布的事件，你必须让两个上下文都引用这个事件对象，这显然加深了模块间的耦合。  
 
-在参考了Abp, Medirator, NServerBus以及微软的示例项目 EShopContainer 我决定自己实现一个服务总线, 它要具有以下特点：
-* 支持隐式注册处理函数
+在参考了Abp, Medirator, NServerBus以及微软的示例项目 eShopOnContainers 我决定自己实现一个服务总线, 它要具有以下特点：
+* 支持委托注册处理函数
 * 支持 Req/Resp 模式
 * 事件的接收与发布对象是非引用的(指你可以在不同模块间建立各自的事件类，只需要保证它们名称与结构相同即可)  
 
@@ -346,4 +347,4 @@ ServiceAnt 在触发处理函数的过程中,可能会产生某些异常,正常
 
 `Abp`: 在上面已经讨论过了, 另外它也不支持 Pub/Sub.如果你的项目不采用多模块的机制, 或者不介意模块间的相互引用, Abp自带的事件还是不错的.
 
-`EShopContainer`: 这只是微软的示例项目，它其中的事件总线是分布式的，有两个实现，一个基于RabbitMQ一个基于AzureMQ, 它也没有作为框架发布到Nuget上.
+`eShopOnContainers`: 这只是微软的示例项目，它其中的事件总线是分布式的，有两个实现，一个基于RabbitMQ一个基于AzureMQ, 它也没有作为框架发布到Nuget上.