@heaventear
老哥你用的哪个套餐？

@ihwbunny
能不能分享一下如何在 pkg 安装的时候索要 root 权限？

@zhaoxin
感谢！

@zhaoxin
我的理解是，最后系统会把你的应用程序拉起来对吧？那么这个程序的运行权限是 root 吗？

感谢 @zhaoxin

现在有了新的 API： https://developer.apple.com/documentation/servicemanagement/smappservice

请问如何以 root 运行后台 LoginItems 程序呢？

@James107
具体优化可以举两个例子吗？

@AerithLoveMe
我个人觉得没有必要：
1. 增加一次网络是否有必要。
2. rpc 服务提供者（ kafka 生产者）是否有必要做成一个单独的服务，因为他功能太简单了。
3. 通过 rpc 发送消息，是否少了很多 kafka 机制，比如丢失消息、重试等。

kafka 或者 rpc 只是邮件服务向外暴露的不同方式而已。

至于引入 kafka 依赖，这不是很正常么？如果不想引入，那就使用 rpc 方式，rpc 也有可能增加依赖。

@PMR
感谢老哥，我看看去。

@byte10
没遇到过循环依赖么...

@summerLast 感谢～

@shot
这个思路跟在 service 上加一层很类似，只不过这一层是 web/app 。

@nothingistrue
非常感谢老哥打这么多字解释。

我理解就是明确每个 Service 的职责和边界，如果需要组合那么这个就不是 User 或者 Order 的职责，这个功能应该放到别的 Service 中。

> 第二，同层之内允许从上到下的调用链，而如果是同层同模块内部，允许双向依赖——不分场合的禁止双向依赖，是违反内聚原则的。

对于这个我有一些疑问：我认为允许同层同模块互相依赖确实可以减少代码冗余，增加内聚，但我们在设计之初是否最好避免互相依赖呢。

能否通过这样的方式：在 service 下加 manager 层，manager 和 service 都不允许同层互相调用，service 可以组合多个 manager ，manager 提供一些细粒度的操作。

@nothingistrue
情况 1：查询用户，带出对应的订单（造成 User 依赖 Order.getListByUserId(long userId)接口）
情况 2：查询订单，带出用户的某些信息（造成 Order 依赖 User.getSomeInfo(long userId)）
请问这种 service 互相依赖怎么解决？

@ChoateYao 那意思是
之前：UserService.get(long id)：获取用户信息->根据用户 ID 获取所有订单信息（造成 UserService 依赖 OrderService ）
改成：为了禁止 service 之间调用，在 service 层上加一层，在这一层组合 UserService 和 OrderService
可以这么理解吗？

@libook 我也是这么认为

有没有同学有比较好的实践

@frank1256 事实确实是你说的那样，很蛋疼。

@Kontinue 是的，主要是后面会出现的，前期没有这个问题。