diff --git a/ch5-web/ch5-07-layout-of-web-project.md b/ch5-web/ch5-07-layout-of-web-project.md
index 3b85668..4fdc55e 100644
--- a/ch5-web/ch5-07-layout-of-web-project.md
+++ b/ch5-web/ch5-07-layout-of-web-project.md
@@ -14,7 +14,7 @@
 
 这种理解显然是有问题的，业务流程也算是一种“模型”，是对真实世界用户行为或者既有流程的一种建模，并非只有按格式组织的数据才能叫模型。不过按照 MVC 的创始人的想法，我们如果把和数据打交道的代码还有业务流程全部塞进 MVC 里的 M 层的话，这个 M 层又会显得有些过于臃肿。对于复杂的项目，一个 C 和一个 M 层显然是不够用的，现在比较流行的纯后端 api 模块一般采用下述划分方法：
 
-1. Controller，与上述类似，服务入口，负责处理路由，参数校验，请求转发
+1. Controller，与上述类似，服务入口，负责处理路由，参数校验，请求转发。
 2. Logic/Service，逻辑(服务)层，一般是业务逻辑的入口，可以认为从这里开始，所有的请求参数一定是合法的。业务逻辑和业务流程也都在这一层中。常见的设计中会将该层称为 Business Rules。
 3. DAO/Repository，这一层主要负责和数据、存储打交道。将下层存储以更简单的函数、接口形式暴露给 Logic 层来使用。负责数据的持久化工作。
 
@@ -129,6 +129,6 @@ type FeatureSetParams struct {
 
 ![control flow 2](../images/ch6-08-control-flow-2.png)
 
-之前我们学习的 middleware 是和 http 协议强相关的，遗憾的是在 thrift 中看起来没有和 http 中对等的解决这些非功能性逻辑代码重复问题的 middleware。所以我们在图上写 `thrift stuff`。这些 `stuff` 可能需要你手写去实现，然后每次增加一个新的 thrift 接口，就需要去写一遍这些非功能性代码。。
+之前我们学习的 middleware 是和 http 协议强相关的，遗憾的是在 thrift 中看起来没有和 http 中对等的解决这些非功能性逻辑代码重复问题的 middleware。所以我们在图上写 `thrift stuff`。这些 `stuff` 可能需要你手写去实现，然后每次增加一个新的 thrift 接口，就需要去写一遍这些非功能性代码。
 
 这也是很多企业项目所面临的真实问题，遗憾的是开源界并没有这样方便的多协议 middleware 解决方案。当然了，前面我们也说过，很多时候我们给自己保留的 http 接口只是用来做 debug，并不会暴露给外人用。这种情况下，这些非功能性的代码只要在 thrift 的代码中完成即可。