我们有一个旧的大型PHP应用程序，具有复杂的业务逻辑。现在，该项目几乎完全由意大利面条代码组成。我计划使用Symfony进行平滑迁移，例如使用Symfoy重写一些功能。DDD似乎也是这个项目的一个很好的选择。因此，主要的想法是对一些功能进行重写，使其更加干净和易于维护。有什么建议吗？
谢谢。
实际上，DDD原则可以应用于遗留代码库重构的上下文中。我们就是这样做的（现在仍在做），但不要把它当作银弹：
第一阶段-战略准备：
1.）使用上下文映射来识别有界上下文及其集成。尽量对您的当前架构保持不可知性。事实上，由于存在偏见，这很难做到。如果你和那些不经常使用旧系统的人一起使用，它就会派上用场。
2.）根据战略价值对上下文进行排序，并确定您的核心域（资金在哪里？），最终找到支持子域和通用子域 3.）将利益相关者、开发人员和产品所有者聚集在一起，在不同的域内形成一种通用语言，即普遍语言，以捕捉业务的意图和能力对这些术语的中心词典要固执，如果你在讨论中听到一些模棱两可的话，解决它并将其添加到词典中。这是任何DDD项目不可分割的一部分，因为我们正在对业务能力进行建模，这意味着代码和利益相关者语言应该具有相同的语义
4.）OTPIONAL：根据组织的规模和工作方法，您可能需要对其进行重组。让Conway定律适用于您，并通过将团队和个人重新分配到您之前确定为价值流的不同领域来创建特定的特征引力，其中最优秀和最聪明的人应该在核心领域工作。实现开发人员和利益相关者之间的直接通信接口，以便在规范和不断提取模型方面密切合作。
第2阶段-实施：
0。）如果你没有这样复杂的重构经验，请寻求外部帮助（顾问）或雇佣有经验的工程师。相信我，你会需要它的（我自己也是通过艰苦的方式学会的）。
1.）创建气泡上下文，在该上下文中，您可以自由地重新设计模型并将其与遗留系统集成。有很多集成模式（你可以在这里和这里找到这些模式的一个很好的总结。总是问问自己，有问题的上下文是否有足够的战略价值，是否会随着时间的推移而发展，是否必须很好地应对未来的变化。最后，这一切都是为了创建一个易于更改和重构的软件。迭代、刷新和重复。总是在获得新代码时尽早重构新代码来自企业的见解。
注意：不要做太多。Bounded Context的作为微服务边界发挥得非常好，但很多时候人们低估了分布式系统的复杂性。如果您没有这种架构所需的可用性和性能要求，那么一个设计良好的模块化整体可能是完成任务的正确工具。
编辑
如果您对DDD的战略部分感兴趣，您必须在此处观看Paul Rayner在DDDEU 16的演讲。
DDD是一套促进团队沟通的方法。它与重构关系不大，与体系结构关系更大。
我不知道这是否符合SO，无论如何，解释都是巨大的。这里没有"银弹"方法。就我个人而言，我会尝试隔离组件，并将它们逐一迁移到一个或多个新的Symfony应用程序中。
DDD与此无关。你可以在Martin Fowler的书中找到很多有用的模式/方法，特别是"重构"answers"企业架构模式"。