更新约定

zh/ater.web/教程/组织代码.md

@@ -16,13 +16,13 @@
 对于多个服务，或者说拆分成微服务，我们可以有不同的实施方案，这取决于您的团队！
 
 > [!IMPORTANT]
-> 对于方案的选择应该考虑开发者的开发体验，这主要体现在开发效率，易实施，小风险等方面，切勿为了实现别人口中所谓的“设计模式”而牺牲自己的精力和时间。
+> 对于方案的选择应该考虑团队的整体开发体验，这主要体现在开发效率，实施难度，风险等方面，切勿为了实现别人口中所谓的“设计模式”而牺牲自己和团队的精力和时间。
 
 ### 共享业务代码的多服务
 
 这种方案非常容易实施，也非常容易理解，它的主要特点如下：
 
-- 我需要在部署时部署多个服务，以让每个服务可以具备高可用。
+- 我需要在部署时部署多个服务，以让每个服务可以具备高可用性。
 - 我的服务共享业务逻辑代码，不同的服务只是开放不同的接口(Http/Grpc)。
 
 这种方案让事情变得简单，假设我们最终要部署三个服务
@@ -46,7 +46,7 @@
 
 - 所有实体在`Entity`中定义
 - 分别创建`UserMod`,`AdminMod`,`OrderMod`三个模块，分别实现各个模块的业务逻辑(即`Manager`)。
-- `Http.API`项目引用 `UserMod`,`AdminService`引用`AdminMod`,`OrderService`引用`OrderMod`。
+- `Http.API`项目引用 `UserMod`, `AdminService`引用`AdminMod`, `OrderService`引用`OrderMod`。
 
 这样可以在业务逻辑上实现拆分解耦，服务只会引用自己的业务实现。
 
@@ -62,7 +62,7 @@
 
 - 是否是多个团队实施微服务
 - 是否使用多种语言实现
-- 是否各个服务采用统一的通讯协议，如统一使用Grpc/Http，或通过消息队列进行服务间通讯。
+- 是否各服务采用统一的通讯协议，如统一使用Grpc/Http，或通过消息队列进行服务间通讯。
 
 这里会涉及到团队之间，服务之间的协作问题，可能会非常复杂。为了简化问题，我们给一些限定，以方便更好的讨论。
 

zh/ater.web/约定和规范/依赖说明.md

@@ -0,0 +1,3 @@
+# 依赖说明
+
+项目模板依赖入以下包或组件：

zh/ater.web/约定和规范/约定.md

@@ -12,21 +12,15 @@
 
 通过`dotnet ef`命令进行数据库结构的迁移。
 
-## CQRS仓储模式
+## CQRS模式
 
-模板提供了两个默认实现的仓储基类`CommandStoreBase`和`QueryStoreBase`，在`Application`项目的`Implement`目录中.分别代表命令(可读写)仓储和查询仓储(只读仓储)
+模板提供了两个默认实现的基类`CommandSet`和`QuerySet`，位于`Infrastructure/Ater.Web.Abstraction/EntityFramework`目录.分别代表命令(可读写)仓储和查询仓储(只读仓储)
 
-使用`droplet`工具会根据您的实体模型，自动生成对应的仓储，分别继承`CommandStaoreBase`和`QueryStoreBase`。在生成的仓储类中，你可以自由实现自己的数据库操作方法。
-
->使用`droplet`生成会自动注入仓储服务，无需手动注入。
->
 ## 业务接口模式
 
-通过接口定义业务方法，模板中提供`IDomainManager`接口，提供`DomainManagerBase`类作为默认实现。
-
-`droplet`会根据您的实体模型，自动生成对应的业务接口和实现类。在生成的业务实现类中，你可以自由实现自己的业务逻辑。
+`dry`目前不再会生成`IxxxManager`接口类，默认只会生成`xxxManager`实现类。你可以根据实际要求自己定义业务接口类。
 
->使用`droplet`生成会自动注入业务接口服务，无需手动注入。
+>使用`dry`生成会自动注入业务实现类，无需手动注入。
 
 ## 接口请求与返回