首先背景
我们公司是一家只有四名开发人员的小型创业公司，它正在开始将我们的产品重构为可重复使用的模块，以简化开发过程，提高生产力，同时，我们还希望在适合的情况下引入单元测试。
像往常一家小型创业公司一样，我们不能浪费太多的开发时间，但正如我们所见，这对我们的业务在中长期的成功非常重要。
目前，我们有两个最终用户产品。两者都是构建在我们自己的内部业务层之上的Laravel（PHP）应用程序，主要由webservices，restful apis和庞大的数据库组成。
此业务层提供这些产品的大部分数据，但每个产品都使用它完全不同。我们计划在不久的将来建造其他产品，除了保持和改进几乎完成的那两个产品。
为此，我们打算将这些（和未来）产品的通用逻辑抽象为可重用和分离的模块。显而易见的选择似乎是作曲家，即使我们对它的了解很少。
现在回到真正的问题
我想就如何以测试驱动的方式开发内部包提出其他意见。每个模块应该是一个作曲家包，它有自己的单元测试并要求它的依赖性，还是我们应该构建一个包含每个模块命名空间的包？
为了澄清一点，我们希望有一个CurlWrapper模块，这在我们的InternalWebserviceAPI模块（以及其他一些模块）上是必需的。
我个人喜欢为每个模块完全分离包并声明对composer.json的依赖的想法，这会在心理上强制解耦，并允许我们有一天将这些包作为opensource发布。它还可以简化对这些模块的更改，因为我们可以在需要更新的依赖项上冻结它的版本。
虽然，我也认为这种分离可能会增加很多复杂性，并且可能更难维护和测试，因为每个模块都需要自己的项目，我们没有足够的人力来跟踪这么多小项目。
Composer真的是我们问题的理想解决方案吗？如果是这样，建议：单包还是多包？
修改1：
我想指出的是，大多数这些模块将是：
答案 0 :(得分：2)
是的，作曲家是最佳选择，我建议您使用单个包。
您不知道何时需要这些模块。最好是创建许多单个包，并且能够将它们全部（或单个）包含在内，而不是创建大包，并且当你需要一些类时，需要花费更多的时间来打破多个包。
例如，请参阅Symfony2项目。这是完整堆栈Symfony2框架所需的许多组件，但您也可以在自己的项目中使用一些组件（如Drupal8正在做的那样）。此外，Symfony2获得了越来越多的软件包，看起来非常有用的是小包装让人们花时间打破一些大包装。
答案 1 :(得分：1)
使用单个包的替代方法：对每个子项目使用separate composer.json files。
这样可以让您将所有库保存在同一个存储库中。在重构代码时，您还可以通过子库对自动加载和依赖关系进行分区。
如果您想要将库旋转到自己的版本化软件包中，您可以进行最后一步并将其检入自己的存储库。