让我们以一个简单的生产流程开始，尽管它跟软件开发没有关系，这样我们能以此为基础定义软件开发中的上下游。
上面的例子有三个步骤：收集部件、组装部件、喷漆。
一个生产流程跟一条河流很相似，所以我们很容易理解：随着流程一步步往下进行，我们在往下游移动。
我们可以推出以下原则：
依赖原则：从自身的角度看，每个环节都依赖其上游的环节
价值原则：往下游移动，每一环节都在产品上增加了价值
现在让我们将这些原则运用到不同的软件开发场景中。
很多软件模块会依赖其他的模块。那么什么是上游依赖和下游依赖呢？
考虑下面关系： 模块 C 依赖模块 B，模块 B 依赖模块 A。
运用依赖原则，我们可以有把握地说模块 A 是模块 B 的上游，模块 B 和模块 C 的上游（尽管箭头是相反的方向）
这里运用价值原则会有点抽象，但是我们可以认为模块 C 拥有最多的价值，因为它导入了模块 B 和 A 的所有功能，并且附加了自己独有的价值。所以模块 C 是下游模块。
开源项目中的上下游另一个“上游”和“下游”被广泛使用的场景是开源软件开发。它跟上面讨论的模块依赖很像。
有两个项目 A 和 B，A 是原始项目，B 是从 A fork 出来的：
这在开源项目中是很常见的开发模式：我们 fork 一个项目，在新项目中修复 bug 或者添加功能之后，提交一个 patch 到原来的项目。
在这个场景下，运用依赖原则：项目 A 是上游项目，因为没有项目 B 它也可以很好地存在，但是项目 B 无法存在如果没有项目 A。
运用价值原则同样可以运用：因为项目 B 增加了一些功能或者 bugfix，跟项目 A 比它增加了价值。
所以每次我们往开源项目贡献一个 patch，我们可以说我们往上游发了一个 patch。
(微)服务中的上下游在由微服务（或者只是过时的分布式服务）构成的系统中，同样有上下游服务的讨论。意料之中，依赖原则和价值原则都可以运用到这个场景。服务 B 是上游服务因为服务 A 依赖它。服务 A 是下游服务因为它在服务 B 的基础上增加了价值。
请注意这里讨论的什么是上游什么是下游中的“游”不是通过服务 A 进入系统的数据流，而是从系统核心部分到面向用户服务的数据流。
离用户（或者其他终端客户）越近的服务，它就越下游。
结论我们可以在任何有“上游”和“下游”的场景中，运用这两条简单的原则来判断哪个是上游哪个是下游。
如果一个事物在另一个事物上增加了价值，或者以任何方式依赖另一个事物，那么它一定是下游。
参考链接：
https://reflectoring.io/upstream-downstream/