代码多，人也多，还需要长期维护，那么我们就不能随心所欲的码，即使框架已经有很多约定。
Yii2规定了MVC , Model是数据处理层，其实绝大部分的业务都应该写在这一层，不要单单的理解成ActiveRecord，因为业务大部分就是数据处理，甚至有一些认为业务应该全部放在Model层，Controller层只负责取数据，组装，把数据交给View层，View层就是模板，如果前后端分离就没有这一层，数据就按格式直接响应出去了。
Controller层要求干净清晰，譬如用户下订单要买点东西场景，这个业务逻辑涉及到的model类有User（用户）、Order（订单）、Goods（商品）... 这样的不管我们把业务放在user的Model，还是Order的Model....,本来Model层业务就比较多了，这样的场景需求一多，会导致Model层迅速膨胀。
又比如，创建用户这个业务场景。你可以在Model里实现一个addUser的方法，把所有事情都做了。你也可以实现一个addUser，checkExist，sendEmail，然后在Controller里 if ($m->checkExist() && $m->addUser()) { $m->sendEmail() }，前一种，addUser在内部做完所有的事情，后一种，实现了三个子操作，在Controller里组装。前一种，Controller里干净了，就一行代码，但是复用性极差，因为别的场景，比如从文件向空DB导入用户的时候，就没必要sendEmail和checkExist，就无法复用第一种的代码，第二种的相对细粒度的，就容易复用。人们愿意细分model的业务，那么controller层组装的代码也会越来越多。
当业务开始复杂起来，我们就需要学会拆分，譬如 在 controller 层 和model层之间可以拆出一个 service层，service层的作用就是把这些需要多个model参与的复杂业务逻辑单独封装出来，这些model之间不再发生直接的依赖，而是在service层内协同完成逻辑。service层的第一个目的其实就是对model层进行解耦，而且还可以专门处理公共且复杂的业务逻辑。
还有view 层 本来很简单，Yii2就直接使用了php模板语言性质，没用其他模板，用起来更随心所欲，在view层去做业务的判断，还会直接用controller里面的变量，函数，用$this->context 直接调用...，完全背离约定。
代码管理要记住 约定优于配置，业务复杂需要学会拆分。