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