声明：仅仅技术探讨。
Frank: 读fecmall代码，全靠经验啊，有ide帮助也效率不高，依赖全靠全局变量注入 深度耦合，我这么说会不会被群友们打，逃/舔一舔
Terry: Fecmall services完全是解耦的设计，何来深度耦合?每一个services都可以通过配置改写，何来耦合?
Terry：Fecmall services无法通过编辑器查找services文件，这个问题的确存在，不过services的命名都是和文件结构对应，约定式命名,这个问题得通过写phpstorm插件解决，如果有高人，可以写一个分享。
Frank：我说了，最大的耦合就是全局变量$services自身，耦合体现在service之间的依赖全部靠全局变量来获取，而不是靠语言本身类之间构造函数来传递service之间的依赖，所以导致了严重的传染性和污染，导致每个涉及业务的地方都出现了那个全局变量，也就是说写代码的人必须要对全局变量services里面有什么有深刻了解，这种“确信目前具体有什么” 比主流依赖注入的“声明要什么”对于开发者来说心智负担更大。
至于通过配置来改写，这种对于全局变量自身来说确实算解耦了没毛病。
不只是ide找service，还有加了前缀action的魔法方法调用这种
Terry:
1.首先，先看业务问题，fecmall作为一个商城，需要按照业务进行划分功能块，譬如cart功能块，产品功能块，订单功能块,而对于一个业务的操作，需要多个功能块完成，譬如：生成订单，需要生成订单，清空购物车，更新优惠卷，更新产品库存,这必然涉及到多个功能的依赖问题，进行解耦
好了，业务问题是将这些功能块解耦，解决强耦合的问题，也就是 a,b,c,d,e,f,g之间的强耦合问题
2.通过Yii::$service->cart的，通过配置注入，容器生成的方式生成单例模式的对象，就是为了解决a,b,c,d,e,f,g的强耦合问题，该模式属于懒加载模式，使用的时候才会实例化单例模式对象，可以通过重写配置重写任意services来解决，这个是吸收了Yii组件的设计思路，参考了Yii::$app->组件的模式思路实现，来解决依赖问题，可以通过配置，更好的重写已有的功能块，譬如：Fecmall可以通过配置的方式，重写Yii框架的一些功能块，譬如：https://github.com/fecshop/yii2_fecshop/tree/master/yii ，里面都是重写的yii2框架的一些类（并不改动yii2的库包文件）
下面将 Yii::$service 用 X 来标识
3.关于耦合：A是零件生产者，B是车企，A生产的零件供货给B，B依赖于A，A的零件的参数变动都会造成B出问题，A和B之间强耦合，现在进行解耦，加入C，c是行业标准，B定义来一个行业标准C给与A，让A必须按照C的标准来进行生产，来实现解耦，由B依赖于A，转变成A依赖于C。
通过行业标准C的加入来实现解耦，那么按照你的思路，加入C，导致了严重的传染性和污染？
4.Fecmall就是通过加入X，解决 a,b,c,d,e,f,g之间的强耦合，你认为X导致了严重的传染性和污染？
请问如果不加入X，如果解决a,b,c,d,e,f,g之间的强耦合？
靠语言本身类之间构造函数来传递service之间的依赖？如何解耦？
通过X的加入，来解决的业务问题是a,b,c,d,e,f,g之间的强耦合，你认为a和X存在耦合是问题？按照你这个逻辑，可真没有存在绝对的解耦，解耦的同时，也是加入新的耦合的过程，非常彻底的微服务，通过api来调用各个方法，这个解耦彻底吧？
但是，按照你的逻辑，同样存在耦合，每一个调用api的功能块和API存在耦合, 导致了严重的传染性和污染？
对于这些讨论，希望论坛发帖子讨论，别Q群乱发东西误导大众。
注1：services加入actionXxxx这种函数方式，是为了每一个service的函数调用，可以在架构上插入一个开始和结束，可以记录各个services函数执行花费的时间，当然，你也可以不用，fecmall的核心代码也没有严格按照这个来，有一些用了actionXxxx方法，有的没有用
注2：至于为什么这样设计，你自己先构思一下，做一个产品，要解决产品的自身持续开发，第三方开发者的插件开发，以及用户自身本地开发，这之间的冲突问题，以及fecmall自身需要升级的冲突问题。
注3：你的问题，可以归结于一个问题，phpstorm无法通过代码定位文件。这个的确存在，对于services，譬如Yii::$service->cart必须解析代码，加载所有的初始配置，才能清楚到底是那个类文件。
laravel框架也存在这个问题，是通过写了一个phpstorm插件来解决的，如果有高人，可以写一个phpstorm插件分享一下。