!89 docs: Improve module and dependency documentation clarity

Merge pull request !89 from bytebistro/abp

Yi.Doc.Md/01.框架快速开始教程/00.快速上手/00.模块与项目.md

@@ -1,5 +1,5 @@
 ## 模块与项目
-意框架是一个基于Abp.VNext的框架，完美使用模块化理念进行开发。既然是模块化开发，就有`项目`与`项目`的概念。
+意框架是一个基于Abp.VNext的框架，完美使用模块化理念进行开发。既然是模块化开发，就有`模块`与`项目`的概念。
 
 很多人问到了我，我的代码应该放到哪里，其实是没有分清楚模块与项目，弄清楚这个，再下手撸码，才更有方向。
 
@@ -7,15 +7,15 @@
 
 > 我接下来要开发的业务是否有必要被其他项目依赖使用？
 
-例如：内置的Rbac模块、Bbs模块，单独具备权限管理和社区论坛的功能，公开给大家复用引用，这就可以当成一个模块
+例如：内置的Rbac模块、Bbs模块，单独具备权限管理和社区论坛的功能，公开给大家复用引用，这就可以当成一个`模块`
 
-`但是`，有时候如果我不认为他有必要复用，就是公司的一个内部系统，想要快速开发并交付，要同时具备权限管理、商城、审批等各种功能，那就直接当一个项目开发即可，不一定需要将各个模块拆的太散
+`但是`，有时候如果我不认为他有必要复用，就是公司的一个内部系统，想要快速开发并交付，要同时具备权限管理、商城、审批等各种功能，那就直接当一个`项目`开发即可，不一定需要将各个模块拆的太散
 
 > 这个划分的界限，是由项目来决定
 
-注意：模块的代码与项目的代码结构几乎没有区别
+注意：`模块`的代码与`项目`的代码结构几乎没有区别
 
-这意味，有一个最好的方式，先将业务全部写在项目中，等稳定之后，在复制抽象到模块中，完全没有问题。
+这意味，有一个最好的方式，先将业务全部写在`项目`中，等稳定之后，在复制抽象到`模块`中，完全没有问题。
 
 ### 模块的优缺点
 - 优点：高度抽象复用
@@ -24,17 +24,17 @@
 ### 模块
 ![Alt text](image.png)
 
-代码位置放在`module`目录下，单独建立一个自己的模块名称,可使用`脚手架使用`将默认代码生成在这里。
+代码位置放在`module`目录下，单独建立一个自己的模块名称,可使用[**脚手架使用**](../05.脚手架使用.md)将默认代码生成在这里。
 
 ### 项目
 ![Alt text](image-1.png)
 
-框架内置一个host项目，代码位置存放在`src`中，直接使用即可，如果想更换命名，可以使用上一节的`脚手架使用`。
+框架内置一个host项目，代码位置存放在`src`中，直接使用即可，如果想更换命名，可以使用上一节的[**脚手架使用**](../05.脚手架使用.md)。
 
 ## 总结
 > 由于很多人询问我这个问题，所以单独写一篇，方便大家理解。
 
-先区分模块还是项目，然后代码写到对应的位置即可
+先区分`模块`还是`项目`，然后代码写到对应的位置即可
 
 理论上，按这套规则意味着，只有在自己的`module`、`src`下才需要写代码，其他地方都是内置好了的，通过继承、实现等方式扩展即可
 

Yi.Doc.Md/01.框架快速开始教程/00.快速上手/01.依赖关系.md

@@ -10,7 +10,7 @@
 
 > 题外话，很是有缘，在完全没有接触过DDD的分层的时候，还是停留在三层架构的时期，对于大型复杂的依赖关系，Service满天飞，根本难以下手，写出的代码交错复杂，稍微隔一段时间没去回顾，再去看，就会被自己的代码给绕死，所以我就一直想换一种分层模式，想让各个服务结构更加清晰，不再是直肠子式的三层架构，那我做的第一件事情，就是把关系比较紧密的给装在一起当成一个整体，各个整体之间不轻易去依赖，而是通过事件去抛出去。这就在早期形成了一套依赖关系比较清晰的框架，经过不断的项目历练，慢慢的就变成了业务聚合、应用组装等等概念，等到机会接触到了DDD分层一看，`哇塞，怎么那么像？这怕不是他抄我的分层嘛`，当然开个玩笑，从此对这块的了解更加加深，确实值得很多大家应该学习的地方，提升一下自己。
 
-> 一千个码农，就有一千个DDD。DDD不一定完全是对的，但一定是值得学习使用的
+> 一千个码农，就有一千个DDD。DDD不一定完全是适合的，并且DDD也从不是银弹，但一定是值得学习使用的
 
 > 在此，老橙子很乐意以我的血淋淋的教训的角度给大家讲清楚，框架的分层依赖关系，同时也是标准的`DDD分层架构`依赖关系，希望能给大家带来一些帮助~
 
@@ -33,7 +33,7 @@
 
 可以从上图很直观的看出：
 
-最顶层的`host主机与下面的应用`没有关系，意味着host主机可以是web、可以是cs、可以等等，所以我们的host主机只充当一个web启动的作用，不包含业务逻辑
+最顶层的`host主机与下面的应用`没有关系，意味着host主机可以是web、可以是cs等等。所以我们的host主机只充当一个web启动的作用，不包含业务逻辑
 
 另外，发现目录中只包含ORM，好像没有基础设施层，其实是一个包含关系，是ORM属于基础设施中的一种，但是为了将orm抽象，特意把ORM独立了一层
 

Yi.Doc.Md/02.框架功能模块教程/01.模块化.md

@@ -2,7 +2,8 @@
 通常，在Asp.NetCore中，**容器组装**过程 与 **管道模型组装** 过程 会将启动类文件变的非常长，同时也需要明确各个模块的依赖关系
 例如：
 我们需要仓储的功能，但是仓储的实现需要依赖Sqlsugar
-老的引入写法：
+
+***老的引入写法***：
 ``` cs
 service.AddUow();
 service.AddSqlsugar();