之前我们在写重构的学习笔记的时候说我们写代码的时候要尽量做到一个类只做领域内的事，不能跨领域做事，不能帮其他领域做事，并要求一个类应该将其相关的业务能力做到最好。对于微服务也是一样的，要进行抽练进行业务的沉淀，然后形成优质代码资产。那么这里说的单一职责原则是否就是这个意思？让我们一探究竟吧！

单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。

单一职责原则其实说的是一种理念，就是各扫门前雪的理念。我们在编写代码中要善于将业务类进行抽练和归纳，让代码更加清晰，小的变动不会引起大规模的改造。这块我们稍微举个例子就是说我们对于一个商品的价格的总价进行计算，如果我们将价格还有打折或者促销甚至积分等业务都合并到一个类中，那么我们这个类将会变的很大，而且如果涉及的商品比较多的时候，甚至商品具有不同的属性，那么用一个类去兼容各种情况未免太傻逼了。最后的最后就是一处改动导致多处改动，在某些情况下开发人员甚至会选择直接类的代码复制过来去兼容新的业务，但是两者代码的相似性很强，所以必然就是代码中的坏味道。针对这种情况，有什么好的解决办法？

我们整个业务流程势必要聚合各种类，也就是说我们已经做好了单一职责，就是将不同的领域内的功能和数据进行拆分。但是考虑与一个决策的过程，那么势必有个聚合决策的过程，这里我们可把以聚合决策的类抽练出来，因为这个类的领域就是决策和调度，因此也符合单一职责原则。在具体的处理类上，因为我们已经将决策的属性外提，因此剩余的部分就是该领域的功能。

综合上边的叙述，我们在开发中应该要善于将逻辑调度进行抽练形成调度器类，而将单一领域内的业务处理下沉形成运算器。这样使得我们的业务流程不再是一个整体，而是多个运算单元和调度单元组成，如果发生修改，那么我仅仅需要修改具体的运算单元或者调度单元即可。

作者大概的想了一下，对于一条业务流程来说，我们的代码要遵循单一职责原则，就应该将代码的组成分为决策调度类和运算单元类的组合模式，如上图所示。

1、两个运算单元类不能直接调度，运算单元类的调度应该由决策调度类进行整合。

2、决策调度类可以任意接纳决策调度类和运算单元类。

我们更认为好的代码应该是形似一棵树，树的分支我们认为就是决策调度类，用来进行上下游资料养分的传递，运算单元类我们可以认为是树叶，主要就是光合作用进行数据加工。树枝上可以长树叶也可以长树枝，但是树叶上是不能长出树枝的。