我们正在使用Symfony2开发电子商务应用程序。它将具有不同的功能，如产品，销售，客户，运输管理等。
它将有3个子系统：Web前端，管理员和RESTful API。
我们应该按功能还是按子系统组织捆绑包？
答案 0 :(得分：2)
嗯，这是你的选择！传统上，如果您浏览Symfony附带的供应商捆绑包以及可用的第三方捆绑包，它们将按功能进行组织。
例如，Sonata Project以核心包开始，并在每个其他包中提供功能。
在将系统拆分为捆绑包时，您应该更关心的是找到一种方法将它们与其他捆绑包分离，这样它们就可以在其他项目中重复使用，只需要进行少量修改，而不是更多配置！你最好的方法（当然只是一种观点）将在捆绑包中单独制作所有这些功能，并将它们与另一捆绑在一起。
根据每个开发者对此事的看法，您可能会发现答案会变得主观。
答案 1 :(得分：2)
我们用Sf2开发了一个电子商务解决方案，一开始我们问自己同样的问题。我们应该围绕实体或子系统（管理员，前端......）组织我们的捆绑包吗？
我们决定采用功能/实体解决方案，并将子系统嵌入到捆绑包中。
让我们做出这个决定的是将功能附加到核心功能的可能性。
例如，我们创建了产品，目录，订单，客户等产品包......这些是您可以在任何电子商务解决方案中找到的基本捆绑包。我们还实施了一个捆绑它们的核心捆绑包。
但我们的一些客户可能希望使用更多功能/插件，如跟踪，资产/图像，报告。 这些捆绑包是可选的，如果我们向客户提供应用程序的代码，我不希望他获得有害/无偿插件的代码。因此，这些功能分为不同的捆绑包，并且它们通过接口和配置文件进行链接。 捆绑包还承载管理面板等子系统应用程序。如果客户端没有跟踪包，则管理面板将不会显示跟踪界面，因为它未在内核中激活。
我希望这会帮助你理解。
答案 2 :(得分：1)
根据symfony's documentation，您可以以您认为合适的任何方式整理捆绑包。这么长时间你坚持编码惯例，以及整体良好的编码实践。特别是如果您计划将此捆绑包发布给公众（在这种情况下可能不是这种情况）。
那就是说，我建议不要按功能组织你的项目，因为功能的数量总会随着时间的推移而增加;而项目中的子系统数量很可能保持不变。
考虑到一个新的bundle，是一个新的子项目要管理，如果你正在使用其他捆绑包或像Assetic这样的库，那么你需要在配置中启用每个捆绑包，所以数字越大捆绑，管理整个项目越困难。
所以，如果我在你的位置，我会在子系统中分解系统。创建一个公开RESTful API的软件包，另一个用于Admin，另一个用于Front-end。
以每个捆绑包可以独立生存的方式构建它们，以防您需要将项目的每个子系统部署到不同的服务器，这样就像将它们从主项目中剥离出来一样简单，并将它们整合到一个新的。