领域驱动设计第三节-战术设计（中）

依赖的环境隔离

由于不同的编程语言的包管理工具，存在对于依赖的 link 机制，所以对于它们的管理也稍有不同：

全局统一依赖型语言的环境隔离。对于诸如 Python、Ruby 这一类脚本型语言来说，它们使用的是全局依赖，所以需要依赖于诸如 virtualenv 或者是 rbenv 为每个项目创造一个独立的运行时依赖环境。

项目独立的依赖隔离。对于使用 NPM 或者 Yarn 的前端开发人员来说，依赖存在于项目目录下的 node_modules，

自然而然地就进行了依赖隔离，但是需要对 Node.js 的版本进行限定。稍微一提，这种机制特别浪费硬盘。

包管理工具版本隔离。统一的依赖存储路径，但是却不需要进行环境隔离，不过需要限定版本。

在引入依赖的时候，我们需要稍微注意一个对于依赖的版本选择问题：到是宽松型，还是严格型。

依赖的版本问题，主要会出现在持续集成和新成员加入项目。

诸如于使用兼容发布条款，如 ~= 0.6.4，对于那些早期已经搭建了的开发来说，并不会有问题。

而新的成员安装的时候，可能就变成了 0.6.5，在 API 上可能会发现一些细微的变化 。

而诸如于使用 * 匹配版本的话，就更不严谨。

由于C#的依赖一般用Nuget虽然有一门辅助语言Zarch用来管理依赖如自动创建并注入使用Attribute标记的类的对象。

用Zarch语言字符串控制被管理的对象的行为。网络传输的Zarch语言字符串以实现RPC功能。

闲来搞U3D用过但手艺问题所以直接跳过（最近在学Go尝试从Go入手依赖管理）

通常一个go中用到以下几种依赖:

内部依赖: 位于项目文件夹内

本地依赖: 位于项目文件夹外, 在文件系统的其他位置中

网络上的第三方依赖

go原生库