有了好的架构还需要好的代码，在编写代码前，我们要区分代码的类型，代码分两种：一个是表达业务逻辑的代码，表达业务逻辑的代码来源于现实生活的切分，是对生活的模拟和虚拟化，另一种是对用户提供访问并保存业务逻辑运行结果的代码，这里有一个值得分析的名词业务逻辑。
业务逻辑是指的是软件代码中的逻辑，不是现实生活中的逻辑，是除代码缩进和计算顺序调用之外的逻辑，以下用严格的顺序调用来指代这种代码。因为顺序调用是计算机的特性，由编译器来决定的，当然最本质的是因为我们计算的基础都是图灵机。在现实生活中，顺序调用也是逻辑，大家不要和我们这里说的业务逻辑相混淆。
Service里面的代码严格的计算顺序调用的代码不需要做单元测试，也很难做单元测试，因为这些代码都需要和很多上下文打交道，所以代码只要做连通性测试即可，由于 Service 代码简单了，才可以让我们的开发人员投入更多的时间研究业务，毕竟这部分才是软件所真正服务的对象。Business 不访问任何上下文，不访问任何具体的设备，因为其他地方没有业务逻辑，所以一旦有问题，就可以断定是 Model 的问题，单元测试肯定可以发现。如果单元测试没有发现问题，那么单元测试一定有问题。线上问题的模拟也就变得非常的简单，单元测试也能够得到进一步的补充。
在实际操作中，不能有逻辑，实际上和很多人的观念是冲突的，认为这个根本做不到。做到这一点需要很多的学习成本，但是一定可以做得到。当发现做不到的时候，可以断定是业务的分析出了问题。比如不该合并的合并了，不该计算的计算了。这个问题一定有办法解决的，做不到都是理由，无非是想早点把自己的工作结束罢了。虽然刚开始会比较困难，一旦把这个观念变成自觉，开发的质量和效率马上就能高好几个级别
刚学习编程程序的时候，碰到一个问题，我们总是想着怎样实现某个功能，而不是思考整个软件的架构问题，那时候只是觉得做架构没什么意思，还浪费时间，但是这样的做法只会更加消耗我们的时间成本，做一个小项目还可以，遇到大项目成本就会指数级增加
参看：架构漫谈