《从架构的角度看，如何写好代码？》这篇文章是一线开发人员实践的经验总结，文字很通俗，应该是基于Java语言环境，但我认为也是符合多数PHP项目团队的所处实践阶段的。
“业余选手，越想从水里浮起来，就越想把头抬起来，身体反而沉下去。只有克服恐惧，把头往水里压下去，身体才能够从水里浮起来。真正专业的习惯往往是和我们日常的行为相反的”。
文章里面提出的代码分层结构如下图：
左侧的要直接面对用户的需求，右侧的更多的需要面对业务的核心。
逻辑只允许存在于右侧Business中，左侧Service、Glue Code、Repository都不允许存在业务逻辑。
分工：
-
Service专注于用户的需求，并组合Glue Code提供的服务完成需求。
-
Glue Code专注于组合business的调用，管理Business里面对象的生命周期，并且通过Repository保存或加载Business的状态。
-
Business专注于实现业务逻辑的核心模型。
-
Repository专注于数据的保存，并和存储设备一一对应。
只要这几块的开发人员互相商量好了接口定义，这几个部分的开发就可以并行的进行，极大的提升开发的效率，缩短开发的时间。
概念详解
Repository
从BM对象传递过来，转换为对应的entity进行数据库操作
Business Model
业务逻辑
在软件代码中，不需缩进和计算的顺序调用，包括缩进的代码目的是catch exception的，都不算逻辑，除此以外都是逻辑。
BM与Entity
Model关心的实际上是业务行为，数据只是是这些行为的结果。所以Glue Code需要把Model转换为Entity（每个Entity对应一张表，并且跟着表的变化而变化），Entity和存储设备里面的存储粒度一一对应，这样就保证存储的变更不会影响Model。
Business Model是必须要重用的，一旦发现重用出现问题，那么说明Business Model的识别出现了问题，这是一个我们要重新思考Model的信号。
在PHP中，重用的标准，可以参考Java的Jar包形式，将BM打包成Phar包独立发行管理。
Business Model必须是一个完美的树状，如果不是，也说明Model的识别出了问题。
Service
确保每个Service只做一件事情。
当多个不同的角色访问同一个接口，一旦某个角色的需求发生了变化，就会要求开发人员去修改，而这个修改往往会影响到其他的角色。尽量给不同的角色不同的Service，避免重用，降低沟通成本。
Service里面没有逻辑的话，开发和管理非常的简单，可以快速应对业务的变化。只有更快地变，更容易的变，才能更好地应对变。
如何写单元测试代码
结论，对BM层的代码进行单元测试。
基于这篇文章，应该可以整理出一套供团队使用的PHP开发框架，包括单元测试的骨架。