《架构漫谈》笔记 - huyx/1 GitHub Wiki

原文：

• 架构漫谈（八）：从架构的角度看如何写好代码

TIPS

考虑部署的架构、代码的架构 软件架构师要解决人的问题 完美的组织是一棵严格的树（多头管理问题）

职责的划分

下图中各个部分的职责：

• Service 就专注于user的需求，并组合Glue Code提供的服务完成需求。
• Glue Code 专注于组合business的调用，管理Business里面对象的生命周期。
• Business 专注于实现业务的核心模型。
• Repository 专注于数据的保存，并和存储设备一一对应。

需要注意：逻辑只允许存在于Business中，Service、Glue Code、Repository都不允许存在业务逻辑。

这么做的好处有哪些呢？

• Service、Glue Code、Repository 里面的代码是严格的顺序调用，不存在业务逻辑，那么这些代码只要做连通性测试即可，不需要单元测试。因为这些代码都需要和很多上下文打交道，很难做单元测试。
• Business 不访问任何上下文，不访问任何具体的设备，所以这部分代码是非常容易写单元测试的，并且单元测试必须100%覆盖。因为其他地方没有业务逻辑，所以一旦有问题，就可以断定是 Model 的问题，单元测试肯定可以发现。如果单元测试没有发现问题，那么单元测试一定有问题。线上问题的模拟也就变得非常的简单，单元测试也能够得到进一步的补充。
• Repository 很容易按照存储设备本身的最小访问粒度来完成工作，比如DB，完全可以做到单表访问。因为这个时候存储设备只关心存取数据，完全和业务没有关系。做表的分拆也是非常容易的事情，存储设备通过增加机器就可以横向扩展长大。很多人会担心说，没有了join，访问DB的次数是不是更多了，会导致性能下降？ 按照现在网络的条件，网络访问和Disk IO访问的差距已经不大了，合理的设计下，多访问几次DB并不会导致这个问题。另外如果多台DB的话，还能通过并行加速访问。
• 由于Service、Glue Code、Repository代码简单了，才可以让我们的开发人员投入更多的时间研究业务，毕竟这部分才是软件所真正服务的对象。