在大型 Java/.Net Enterprise 项目中，是否每个开发人员都需要在其类路径/本地开发环境中拥有所有组件/库/依赖项才能构建它？
还是将它们分成更小的部分，可以单独构建（这样它们就不需要引用所有依赖项）？
换句话说：如果他们想运行整个应用程序，他们需要所有组件；但如果他们只运行应用程序的一个子集，他们将只需要相应的组件子集。
大型企业项目通常采用第一种方式还是第二种方式组织？
一个可能的组织是，如果您正在处理整个项目的一个模块，该模块是自包含的，但被其他模块引用（换句话说，依赖树中的叶节点）。
另一个组织是，如果您动态加载您使用的类，您可以在类路径中不包含任何类的情况下进行构建。要运行它，您的类路径只需要访问您实际加载的那些（可能有许多其他组成项目的不同部分，您不加载）。
这些是理论上的可能性；但是企业项目的标准做法是什么，在……好吧，在实践中？
我已将其扩展为包括 .Net，因为我认为那里会出现同样的问题（DLL 地狱？）
对于每个项目，这个问题都有不同的答案。一般的几点：
他们可能只需要一个子集来构建，另一个子集来运行他们的测试，但是因为所有不平凡的 Java 项目的依赖关系很快就会成为跟踪的噩梦，Java 开发人员已经开始喜欢开发一个与他们精心设计的构建系统（例如 Maven）之间的爱/恨关系，这些系统为他们管理开发环境。
对于不使用此类系统的项目，通常最简单的方法是始终包含所有内容。权衡是不必要的臃肿的开发环境，而不是花时间来追踪丢失的依赖项。
一个好的项目结构将分解事物，以便您可以运行独立的模块。
但在现实生活中，我见过的大多数项目都不会这样做，直到有人厌倦并主动打破它们。
如果你正确地使用了像 Maven 或 Ivy 这样的良好依赖管理基础设施，你可以将编译后的模块存储在服务器上，并根据需要下载这些依赖。
您还可以使用许多模拟对象和服务来帮助分解对其他产品组件的测试依赖性。
我当然同意将事物分开是“好”的评论。但在实践中，这种情况非常罕见。
假设你必须在一个没有分离的环境中工作，还有另一种组织策略，这就是我所看到的。由于您的问题涉及构建和运行依赖项，因此您似乎不是在谈论进程，而是在谈论类和 jar。
一个简单的解决方案是在共享服务器上建立完整的、集成测试的（或集成测试就绪的）依赖项。
然后开发人员在他们的本地环境中构建他们正在工作的系统部分，使用首先引用他们的开发，然后是适当的共享服务器的类路径。
在我看来，这不是开发人员是否可以在应用程序的子集上工作，而是管理组成应用程序的项目（想想 Eclipse 项目）之间的依赖关系。通常，您可能有一棵此类项目的树，其中一个或多个项目可以依赖于其他项目。在这种情况下，上游/普通项目的作用通常是确保下游项目不会因为上游项目的变化而中断。
可以这样想 - 假设您有一个utils项目，其中放置了应用程序的所有通用/实用程序功能 - 这可能是验证逻辑、字符串实用程序、日志记录等。并且您有许多其他项目使用来自这个utils。
utils
/ \
proja projb
在这种情况下，工作人员也utils 应该拥有他们proja 的 projb开发环境，因为任何更改utils都会破坏他们。但是，如果您只是在工作，projb那么您可能不必包含proja，因为您不依赖该项目。
您的问题不是很清楚，但我认为答案是您的应用程序需要的每个类都必须位于 CLASSPATH 或带有抛出 ClassNotFoundException 的类加载器中。
无论您是独立开发人员还是在更大的分布式团队中工作，这都是正确的。
根据我的经验，应用程序是以一种方式打包的。如果您只想要一个子集，则必须将其打包。
如果您将测试用例视为单独的东西，那么它们通常不会与生产代码一起打包。