@shakaraka #9 差不多这个意思，但它写的例子不对
export async function getUserById(id: string, repo: UserRepo) {
return repo.findById(id);
}
这种做法只是另一种脱裤子放屁的实现

当我们用面向对象思想组织代码，会将变量与函数实现放在 class 中，没有全局作用域的语言必须这么做。
这会导致一个问题，我必须先有一个对象，然后才能调用这个函数，这导致一句著名的话："你想要得到一根香蕉，但结果却得到了一个拿着香蕉的大猩猩，以及整片丛林"，那七八百行就是当前上下文的丛林。

如果换成偏向函数式的 js 来写，import domain/server/repository 等方式是冗余甚至有害的，因为这些对象有着依赖关系。
我通常不会主动创建任何不必要对象，函数只是函数，它们可以有一个主人，例如当前的 js 文件本身，等待其他文件对它进行调用，不需要特地装进一个箱子，或者大中小三个箱子。

像 userService.getUserById() 之类的写法完全没必要，userService 是一个冗余的命名空间
import { getUserById } from '@/xxx/user' 就行
绝大多数情况下分层也是没必要的，这反而加大了业务理解难度
不需要得到这个函数后面的所有隐式依赖对象，简单地得到这个函数本身然后调用它就行
要得到一根香蕉，只需要执行一个能获得一根香蕉的函数。
那么所有的依赖关系就只留在互相调用之中，没必要特地去管，尝试无意义的解耦没有太明显的好处。

一直以来用不用 DI 有争议，我是选择了不使用 DI 的阵营，并且应用于大型项目。
https://stackoverflow.com/questions/9250851/do-i-need-dependency-injection-in-nodejs-or-how-to-deal-with
喜欢 DI 的人会使用面向接口而非面向实现更好这个理由，但我一直认为是坏处，面向函数、面向类型/契约编程，需要编写的代码更少且更安全。